Re: [Qemu-devel] multihead & multiseat in qemu

[Dave Airlie]

On Fri, Mar 21, 2014 at 11:27 PM, Gerd Hoffmann <address@hidden> wrote:
>   Hi,
>
> I'm thinking about how to handle multihead and multiseat in qemu best.
>
> On multihead:  Mouse in virtual machines works best with absolute
> coordinates, and the way this is done today is to assign a (virtual) usb
> tablet to the guest.  With multihead this becomes a bit difficuilt.
> Today we try to calculate the coordinates for the tablet that they cover
> all displays, which has a number of drawbacks.  I think it would be
> better to operate more like a touchscreen, i.e. have one touch input
> device for each monitor.  For that to work the guest must know which
> touch device belongs to which monitor.

Yeah I think I'm in agreement with this, one touch device per monitor,

> On multiseat:  Very simliar problem here (thats why both issues in one
> mail):  The guest needs to know which devices belong to which seat.
>
> Qemu needs the grouping/assignment information too, to the the input
> routing right (i.e. input from this window needs to go to that virtual
> input device etc).  Doing the configuration twice (once for qemu, once
> for the guest) and make sure they actually match would be annoying
> though.  So I think we should configure qemu only, then pass that
> information to the guest somehow.
>
> Question is how to do that best?

The GNOME guys have been working on auto config of touch devices,
I need to find who is doing that work and what they are triggering on,
since X just provides the devices currently, I think we might need some agent
in the guest for this.

>
> I'd like to have some way to assign tags such as seat=foo or head=1 to
> devices.  Preferably in some way which can easily picked up with udev
> rules, so it is easily usable by system-logind and Xorg server.

The only current example of seat autoconfiguration is for the usb hubs
from displaylink I think, which have video/audio/ethernet/usb behind a
hub that udev detects as being part of a seat, I'd need to look up the
specifics,

> We have virtio devices (virtio-gpu for example).  For these it is easy,
> we can put something into the virtio protocol, and the guest driver can
> create a sysfs file where udev/systemd can pick it up.
>
> We have pci devices (cirrus for example).  One idea for them would be to
> create a vendor-specific pci capabiliy for tags.  Probably needs some
> small utility to read them, or kernel driver support to export them via
> sysfs.
>
> We have usb devices (kbd/mouse/tablet).  We could put something into the
> string table, or have some vendor-specific descriptor.  Same problem
> here, not easy accessible, needs a tool or kernel support.
>
> Comments?  Better ideas?  Other suggestions?

It does seems like tagging the devices somehow would be better than providing
a seat device, like we could in theory have a pci and usb controller
per seat, and
have devices move around between them, this would be like what we for
the real hw,
however per-device tags does look like it might be nicer in the long run.

Dave.