Another approach to multitouch handling

[Carlos Garnacho]

Hi!,

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.

=The Problem=

        * 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 proposal=

        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.

=The code=

        http://cgit.freedesktop.org/~carlosg/xf86-input-evdev/log/?h=multitouch-subdevs
        
        I've started off Benjamin's multitouch-subdevs branch for this
        proof of concept.

Ideas? comments?

Cheers,
  Carlos