Hello Gerd,
14.12.2016 11:11, Gerd Hoffmann wrote:
So I would be interested to know whether anyone else has thought about
this problem, and possibly even about an interface to let the compositor
pass the information. If not, would people be open to the idea? I
would much rather have something generally agreed on than hack something up.
I think the best way to tackle this is to have multiple tablets, one per
display device (touchscreen-style setup).
qemu can do that, with input routing (must configure on the host which
display belongs to which tablet). Here is some info on that:
http://git.qemu-project.org/?p=qemu.git;a=blob;f=docs/multiseat.txt;hb=HEAD
The setup on the guest side is completely manual. You have to use
"xinput --map-to-output" to tell Xorg which tablet belongs to which
display. Maybe it is also possible to stick that into xorg.conf.
Should be improved, and it surely makes sense that qemu and virtualbox
use the same approach here.
Not sure if and how this works automatically with physical touchscreens.
Any clues are welcome.
Thanks for the answer. That was the direction I was initially expecting
to go too. In theory libinput lets you map input devices to heads[1]
using a udev property[2], though I have yet to test whether anyone
supports that yet (couldn't find it in the Mutter/GNOME Shell source,
but I'm not familiar with it). As the API description says, the default
without that property is still to map the input device to all screens
like X.Org on Linux does.
[1]
https://cgit.freedesktop.org/wayland/libinput/tree/src/udev-seat.c?id=1.5.3#n97
[2]
https://wayland.freedesktop.org/libinput/doc/0.99.1/group__device.html#gaf48626f6190e9c9bc14abb704e66cc22
Another option is to use a guest agent, spice does that since years to
handle multihead. The guest agent queries the display layout using
xrandr, gets x + y + displayid from the spice client and generates
pointer events from that. But I expect that scheme breaks with wayland
because wayland is by design alot more restrictive, so spice-agent
probably isn't allowed to send pointer events. So not really an option
these days ...
We actually do something similar in Windows guests: older versions
provided the layout information to the driver directly, but at least
Windows 10 does not, so we query it with a user-space agent which passes
it to the driver. (We send our pointer events from a driver, in all
supported guest types, which works fine with Wayland too.) It would be
nice though as I said if the compositor (or whoever is controlling the
display) could just provide the layout information to the driver itself.
We already have "suggested X" and "suggested Y" for the other
direction, and for now I have solved it by always providing "suggested
X" and "suggested Y" hints in the driver. That which works well enough
in a first approximation - if the user changes the layout inside the
virtual machine the mapping breaks, and as soon as they change it
outside it mends again. So my idea was to try to have people agree on
on interface for that.
Regards
Michael
cheers,
Gerd
--
Michael Thayer | VirtualBox engineer
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister
der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
