multi-touch-dev team mailing list archive

[Chase Douglas <chase.douglas@xxxxxxxxxxxxx>]

On 02/07/2011 06:25 PM, Chase Douglas wrote:
> Henrik and I had a great discussion today. I'm going to try to summarize
> the conclusions:
> 
> 1. We need to have timeouts for system, or global, gestures. A system
> gesture takes precedence over sending events to clients, so we need to
> make a decision within a reasonable interval whether the sequence
> initiates a global gesture or not. This is what is currently in grail
> 1.0.19 as it exists in the xorg-unstable ppa, though it also applies the
> timeouts to non-global gestures as well.
> 
> 2. For non-global gestures, instead of sending either gesture events XOR
> xi 2.1 multitouch events we can send both simultaneously and have the
> client sort it out. This allows us to always send xi 2.1 events and
> recognize gestures at different points throughout the touch stream. I
> think we will always want the xi 2.1 events to be sent first so the
> client has the full context of multitouch before gesture events come in.
> 
> I think this will be an excellent solution for grail 2 because it will
> have the touch id and event ids from X to send as properties of gesture
> events. This will allow easy client xi 2.1 to gesture event matching.
> Unfortunately, this will be trickier with grail 1. If we don't manage to
> get grail 2 into natty, the client may need to perform some heuristics
> to match xi 2.1 event ids to gesture ids. We'll look at this more fully
> in the future.
> 
> 3. The big area of confusion between Henrik and myself was whether
> events can and/or should be sent to multiple windows for the same
> sequence of touches. For example, in X and OS X today you can put two
> fingers down and scroll in one window, lift a finger, move the other
> finger to position the cursor over a different window, then place
> another finger down again to scroll in the new window. This boils down
> to sending events to two separate windows for the same touch, in this
> case the touch that is never lifted through the process.
> 
> I thought Henrik was wanting this level of support, since it's how
> things work today. However, we both agree that this is an untenable
> design. Touches must only affect one window (a simplification, but
> applicable here) for the duration of their lifetime.
> 
> We believe that combining 1 and 2 will allow for the use case Henrik
> would like to see. I will work on implementing this in grail 1, and
> Henrik will use this approach as he works on grail 2.

Unfortunately, I found a devil in the details...

I went and implemented what was described above. Unfortunately, there's
a nasty side effect with respect to pointer emulation. If we send
gestures at the same time as xi 2.1 multitouch events, the xi 2.1 events
will be translated to pointer motion for legacy applications.

Let's take Inkscape + ginn for an example. Ginn listens for two finger
pinch and drag for zoom and scroll. Now we perform a two finger drag to
scroll. Ginn gets the gesture events and scrolls the canvas. However,
Inkscape also receives the events in the form of pointer motion. Now
we're drawing on the canvas at the same time as we scroll. Obviously,
this won't do :).

One argument might be that we should control pointer emulation in the
uTouch stack, similar to what we have done in Maverick. However, this
isn't really an option. Pointer emulation is intrinsically tied to X
event subscriptions, including both xi 2.1 MT subscriptions and
traditional pointer motion subscriptions. The current working document
showing the flow chart of pointer emulation can be seen at
http://people.freedesktop.org/~whot/patches/mt_events.svg (Beware! Open
it in Inkscape, Chromium crashed my netbook trying to render it). In a
more perfect window system, pointer and touch motion would be separated
enough that we might be able to get away with what's outlined above, but
we can't in X.

Unfortunately, I believe this leaves us with no choice but to keep what
we have in the xorg-unstable ppa right now, which does not send X events
when gestures are being performed.

Thanks,

-- Chase