Another approach to multitouch handling
carlos at lanedo.com
Wed Jun 2 07:40:34 PDT 2010
I've been discussing with Peter Hutterer about the convenience of the
"touchpoints as multiple valuators" approach, and how it could (IMHO)
delay adoption in the short/mid term for anything related to multitouch.
* Confines multitouch to a single client/Window: This is a well
known problem, to my knowledge only done to have proper
interaction with the paired keyboard.
* Exposes TrackingID right up to the client. This is an
implementation detail, and it's sometimes even made up,
depending on the hardware.
* Makes it harder to toolkits to abstract the proper bits. I've
myself ported GTK+ to use XI2, and there's a lot of code to keep
track of (implicit) grabs, window under pointer and such, and
quite some other GTK+ features depending on that (::grab-broken
signal, synthesizing crossing events with
client-side-windows, ...). All that infrastructure would need to
be duplicated, instead of using well-tested code paths.
* Makes development harder. People developing applications with
multitouch in mind are required to have specialized hardware for
testing, this is key in short term adoption. Having multitouch
devices behaving as close as possible to multiple pointers would
enable developers to do basic testing with some spare mice.
* Potentially requires a switch in the future. Most likely, X
wants touchpoints to resemble pointers for most things (position
querying and such), so toolkits and clients will be in moving
grounds if multitouch is adopted too early.
The multitouch capable hw device would have a main device
created, which is able to send core events and be attached to a
MD, the evdev driver would also create several floating devices
(one for each touchpoint), unable to send core events nor to be
attached to a MD (I've disabled XI86_POINTER_CAPABLE for these,
but the server doesn't seem to honor that).
The only purpose for the main device would be routing events for
one of the floating touchpoints. Whenever a new touch happens,
and the main device isn't already routing events from another
touch, the events that such touchpoint generates would be sent
through the main device instead.
This means that there would be N+1 devices for N touchpoints, so
at least 1 of these devices wouldn't be sending events, this
makes touchpoints somewhat anonymous for multitouch purposes,
but the routed touchpoint would remain constant as long as it's
operating on the device (press -> ... -> release). This also
provides sane backwards compatibility, non-XI2 clients would
just see core events from the main device.
I've been experimenting with this concept, and together with a
~200LOC patch to GTK+ master (master is already XI2 capable)
I've got things working out of the box, also wrt hotplugging.
I've started off Benjamin's multitouch-subdevs branch for this
proof of concept.
More information about the xorg-devel