Another approach to multitouch handling

[Peter Hutterer]

On Mon, Jun 07, 2010 at 01:33:05AM -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).

There's other reasons where you don't want that though, so limiting to one
case is dangerous.
 
> >         * 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.

> >         * 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).

uinput (and/or evtest-capture, if you have a real device) should get you
there in no time.

Cheers,
  Peter

> >         * 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.
>