multi-touch-dev team mailing list archive

[Ping Cheng <pinglinux@xxxxxxxxx>]

Hi Chase,

I didn't have time to look into your Grail/Geis design in-depth. My
comments are based on what I leant from your presentation at XDS. And
it is based on the coming XInput 2.1. That is, I assume we have MT
support in the X server.

Tell me as soon as I lose you.

Ping

On 10/4/10, Chase Douglas <chase.douglas@xxxxxxxxxxxxx> wrote:
> As I've thought some more about the current grail architecture and the
> future when we have XInput 2.1 with full multitouch support, I realized
> there may be an issue with our current implementation.
>
> Grail currently takes MT input and looks for a subscribed gesture. If
> there wasn't any, the MT input is discarded (leaving aside single touch
> emulation). Once XInput 2.1 is available, including when we move gesture
> recognition to the client side, we'll need to be able to pass through MT
> events. A wrinkle is that we need to be able to support MT grabbing as
> well.

I think most of what you do now in Grail would be handled by XInput
2.1. We may still need to keep mtdev to translate type A to type B.
But that is very much device specific. I think your current Grail or
the coming XInput 2.1 deals with generic system wide MT events. Right?
So, once XInput supports MT grabbing, it would be up to the client to
tell X server that it is grabbing the events or not. Grail/Geis would
be in the same position as all the other clients, assuming Grail and
Geis will deal with system wide (or Unity in your term :) MT gestures
on Ubuntu then.

> When I thought about MT grabbing, I realized that grabbing really needs
> to be done on a per-finger basis, and the client needs to decide early
> on whether to grab the touch through the entire touch, or whether it
> should allow events through to non-grabbing clients.

I don't feel per-finger grabbing would work. My view of grabbing works
like this: when the touch points/contacts are inside an MT enabled
client, the client grabs the events and translates them into its
specific events/gestures. The client ungrabs the events when all the
touch points leave the surface. Next time when MT events coming in,
grabbing will be decided again base on which client the touch points
are in. Unity grabs the events if the touch points cover more than one
client. Same thing happens to Unity. It ungrabs the events only when
all touch points leave the surface.

> Imagine you perform a two finger pinch gesture and then move directly
> into a two finger drag. If a client subscribes only to the drag gesture,
> it will receive gesture events for the drag once grail starts to
> recognize it. However, this breaks down when we try to involve MT grabs.
> We would need to wait through an entire touch sequence until a
> subscribed gesture is found before we can decide whether to handle all
> the events ourselves or replay them to other clients.

I don't think Grail or XInput can make the decision. It is the client
who needs to make the decision. I think most gestures are client
specific. Grail/Geis can only deal with the system wide generic
gestures. So, it should not care about if a client is doing a draging
or pinching. It only knows that the client is grabbing the events. If
the client doesn't support MT or doesn't grab the MT events by some
reason, Unity kicks in to translate those MT into system wide
gestures. Unity comes into play the last. It is a system wide default,
which could be different for different distributions, I guess.

> What I think we'll need to do is modify grail so that it recognizes a
> subscribed gesture very soon after a touch begins. If no gesture was
> recognized, the touch needs to be passed through as normal MT events for
> the remaining duration of the touch. This allows a grabbing client to
> make a decision on whether to replay events for the touch to
> non-grabbing clients. This also means grail can't recognize gestures
> based on touches that have already been disposed to pass-through status.

I think I've covered this part already.

Ping