Another approach to multitouch handling

[Carlos Garnacho]

Hi!,

On Mon, 2010-06-07 at 01:33 -0400, Rafi Rubin wrote:
> Some more targeted comments.
> 
> >          * 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.
> 
> There are pointer specific reasons that you might want to keep a stray finger 
> tied to the group.  Imagine you've got a grip on an object in blender and a 
> couple fingers stray off the edge of the window, they are still a part of the 
> action and you don't want to "drop the ball" (bad joke not entirely unintentional).

Implicit grabs would also fulfill that, right? AFAICT, traditionally
touchscreens have emitted ButtonPress as soon as the finger touches the
screen, that's also how my driver branch behave, so there would be one
implicit grab in effect per finger touching the screen.

> 
> >          * Exposes TrackingID right up to the client. This is an
> >          implementation detail, and it's sometimes even made up,
> >          depending on the hardware.
> 
> I agree the tracking should be annotated with source and confidence in the 
> quality.  That doesn't mean we shouldn't track and cluster early, clients that 
> know better should be able to ignore that tracking, but optimize for the common 
> case and let more typical applications use generic tracking data.
> 
> >          * 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.
> 
> For these questions, I don't think you should special case at all.  Just treat 
> grabs, focus, etc like a conventional pointer.

Which takes us back to single-client multitouch :).

IMHO, XI2 has introduced a lot of new semantics for clients to handle,
one question mark currently opened, left out to toolkits, is how
multiple devices get to interact within a single client. Multitouch
feels like a concrete issue in the general case, so it will likely just
add confusion if we have to face an entirely different set of concepts
to handle something we also need to handle elsewhere.

For example, in GTK+ I reused and extended the grab ownership concept,
so you can get from "this app only gets events from this device pair" to
"no restrictions", multitouch is somewhere in between, closer to the
latter. Thanks to this, the changes required in GTK+ to support
multitouch (as of my evdev branch) are minimal.

> 
> >          * 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.
> 
> I agree.  We should get together a virtual device that works with multiple live 
> pointing devices and possibly even play back independently recorded input 
> streams.  (Such a tool may also be valuable to regression testing).
> 
> >          * 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.
> 
> Lets settle on the fundamentals, then if we change the core a bit, it should 
> only be a slight mod to a thin layer.

I see though some conceptual problems in making the multiple valuators
approach work with multi-client multitouch, so if there are plans to
support that, it will likely take more than slight modifications to get
there.

Regards,
  Carlos