Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS

From: Gerd Hoffmann <kraxel@redhat.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Hans de Goede <hdegoede@redhat.com>,
	David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org,
	Gurchetan Singh <gurchetansingh@chromium.org>,
	krastevm@vmware.com, Pekka Paalanen <ppaalanen@gmail.com>,
	mombasawalam@vmware.com, Thomas Zimmermann <tzimmermann@suse.de>,
	wayland-devel <wayland-devel@lists.freedesktop.org>
Subject: Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
Date: Fri, 10 Jun 2022 14:36:29 +0200	[thread overview]
Message-ID: <20220610123629.fgu2em3fto53fpfy@sirius.home.kraxel.org> (raw)
In-Reply-To: <YqMTk9C8/g1buL+8@phenom.ffwll.local>

  Hi,

> > As Pekka mentionned, I'd also like to have a conversation of how far we want to
> > push virtualized driver features. I think KMS support is a good feature to have
> > to spin up a VM and have all of the basics working. However I don't think it's
> > a good idea to try to plumb an ever-growing list of fancy features
> > (seamless integration of guest windows into the host, HiDPI, multi-monitor,
> > etc) into KMS. You'd just end up re-inventing Wayland or RDP on top of KMS.
> > Instead of re-inventing these, just use RDP or waypipe or X11 forwarding
> > directly.

> > So I think we need to draw a line somewhere, and decide e.g. that virtualized
> > cursors are fine to add in KMS, but HiDPI is not.

What is the problem with HiDPI?  qemu generates standard edid blobs,
there should be no need to special-case virtualized drivers in any way.

What is the problem with multi-monitor?  That isn't much different than
physical multi-monitor either.

One little thing though:  On physical hardware you just don't know which
monitor is left and which is right until the user tells you.  In case of
a virtual multi-monitor setup we know how the two windows for the two
virtual monitors are arranged on the host and can pass that as hint to
the guest (not sure whenever *that* is the purpose of the
suggested_{x,y} properties).

> It's getting a bit far off-topic, but google cros team has an out-of-tree
> (at least I think it's not merged yet) wayland-virtio driver for exactly
> this use-case. Trying to move towards something like that for fancy
> virtualized setups sounds like the better approach indeed, with kms just
> as the bare-bones fallback option.

virtio-gpu got the ability to attach uuids to objects, to allow them
being identified on the host side.  So it could be that wayland-virtio
still uses kms for framebuffers (disclaimer: don't know how
wayland-virtio works in detail).  But, yes, all the scanout + cursor
handling would be out of the way, virtio-gpu would "only" handle fast
buffer sharing.

take care,
  Gerd