From: Daniel Vetter <daniel@ffwll.ch>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: dri-devel@lists.freedesktop.org,
Vivek Kasireddy <vivek.kasireddy@intel.com>,
Dongwon Kim <dongwon.kim@intel.com>
Subject: Re: [PATCH v1 2/2] drm/virtio: Add the hotplug_mode_update property for rescanning of modes
Date: Wed, 11 Jan 2023 23:08:48 +0100 [thread overview]
Message-ID: <Y78zcBZx1AKt1SgT@phenom.ffwll.local> (raw)
In-Reply-To: <20230110092839.3mx7dcbhj2w7hm5q@sirius.home.kraxel.org>
On Tue, Jan 10, 2023 at 10:28:39AM +0100, Gerd Hoffmann wrote:
> On Fri, Jan 06, 2023 at 10:35:15AM +0100, Daniel Vetter wrote:
> > On Fri, Jan 06, 2023 at 09:56:40AM +0100, Gerd Hoffmann wrote:
> > > On Thu, Nov 17, 2022 at 05:30:54PM -0800, Vivek Kasireddy wrote:
> > > > Setting this property will allow the userspace to look for new modes or
> > > > position info when a hotplug event occurs.
> > >
> > > This works just fine for modes today.
> > >
> > > I assume this is this need to have userspace also check for position
> > > info updates added by patch #1)?
> >
> > What does this thing even do? Quick grep says qxl and vmwgfx also use
> > this, but it's not documented anywhere, and it's also not done with any
> > piece of common code. Which all looks really fishy.
>
> It's again a virtualization-specific thing. On physical hardware you
> typically have no idea which of your two monitors stands left and which
> stands right. On virtual hardware the host knows how the two windows
> for the two heads are arranged and can pass on that information to the
> guest. suggested_x/y properties added by patch #1 do pass that
> information to userspace so the display server can arrange things
> correctly without manual invention.
Yeah suggested_x/y I know about. Would still be good to fix the
documentation situation for that.
> I have no clue though why this hotplug_mode_update property exists in
> the first place and why mutter checks it. IMHO mutter could just check
> for suggested_x/y directly.
This one is the complete wtf here. I have no idea why this exists.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2023-01-11 22:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-18 1:30 [PATCH v1 0/2] drm/virtio: Add hotplug_mode_update and suggested_x/y properties Vivek Kasireddy
2022-11-18 1:30 ` [PATCH v1 1/2] drm/virtio: Attach and set suggested_x/y properties for the connector Vivek Kasireddy
2023-01-10 9:33 ` Gerd Hoffmann
2022-11-18 1:30 ` [PATCH v1 2/2] drm/virtio: Add the hotplug_mode_update property for rescanning of modes Vivek Kasireddy
2023-01-06 8:56 ` Gerd Hoffmann
2023-01-06 9:35 ` Daniel Vetter
2023-01-10 1:58 ` Kasireddy, Vivek
2023-01-11 22:12 ` Daniel Vetter
2023-01-12 7:17 ` Gerd Hoffmann
2023-01-12 9:17 ` Daniel Vetter
2023-01-10 9:28 ` Gerd Hoffmann
2023-01-11 22:08 ` Daniel Vetter [this message]
2023-01-10 1:42 ` Kasireddy, Vivek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y78zcBZx1AKt1SgT@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=dongwon.kim@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kraxel@redhat.com \
--cc=vivek.kasireddy@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.