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
