[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] multihead & multiseat in qemu
From: |
Dave Airlie |
Subject: |
Re: [Qemu-devel] multihead & multiseat in qemu |
Date: |
Sat, 22 Mar 2014 07:55:55 +1000 |
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.
Re: [Qemu-devel] multihead & multiseat in qemu,
Dave Airlie <=