From: Daniel Vetter <daniel@ffwll.ch>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"Kasireddy, Vivek" <vivek.kasireddy@intel.com>,
"Kim, Dongwon" <dongwon.kim@intel.com>
Subject: Re: [PATCH v1 2/2] drm/virtio: Add the hotplug_mode_update property for rescanning of modes
Date: Thu, 12 Jan 2023 10:17:11 +0100 [thread overview]
Message-ID: <Y7/QFwsKU1qBSKzv@phenom.ffwll.local> (raw)
In-Reply-To: <20230112071719.syjcv7hn6qekatog@sirius.home.kraxel.org>
On Thu, Jan 12, 2023 at 08:17:19AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > > I think we need to do a bit of refactoring/documenting here first.
> > > [Kasireddy, Vivek] Just for reference, here is Dave's commit that added this
> > > property for qxl:
> > > commit 4695b03970df378dcb93fe3e7158381f1e980fa2
> > > Author: Dave Airlie <airlied@redhat.com>
> > > Date: Fri Oct 11 11:05:00 2013 +1000
> > >
> > > qxl: add a connector property to denote hotplug should rescan modes.
> > >
> > > So GNOME userspace has an issue with when it rescans for modes on hotplug
> > > events, if the monitor has no EDID it assumes that nothing has changed on
> > > EDID as with real hw we'd never have new modes without a new EDID, and they
> > > kind off rely on the behaviour now, however with virtual GPUs we would
> > > like to rescan the modes and get a new preferred mode on hotplug events
> > > to handle dynamic guest resizing (where you resize the host window and the
> > > guest resizes with it).
> >
> > Ok this is just terrible. Because _anything_ without an EDID is impacted,
> > and we're certainly not going to sprinkle this property all over gpu
> > drivers just so Gnome takes the right path.
>
> Oh, and (newer) virtio-gpu actually has EDIDs ...
I forgot to mention. If userspace is worried about the expensive probe
cycle that calling the GETCONNECTOR ioctl can cause. There's
drmModeGetConnectorCurrent. But that's not guaranteed to give you up to
date info after a hotplug event, depending upon driver :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2023-01-12 9:17 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 [this message]
2023-01-10 9:28 ` Gerd Hoffmann
2023-01-11 22:08 ` Daniel Vetter
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=Y7/QFwsKU1qBSKzv@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.