[RFC] Multitouch proposal v2 + implementation

[Benjamin Tissoires]

Hi Daniel,

though I'm not a toolkit guy, I wanted to add some comments mainly from 
the discussions we had at XDS (and from what I understood).
I've also added Denis in copy as he was present at XDS and may need to 
add sth.

Le 20/09/2010 06:45, Daniel Stone a écrit :
> Hi all,
> This is my second draft of the multitouch proposal, along with a fairly
> complete implementation; patchsets for inputproto, xserver,
> xf86-input-evdev, libXi and xinput follow.
>
> This is more or less half way between Peter's proposal and my original
> one: it doesn't use valuators anymore, but it has a different, and
> hopefully more workable, approach to grabbing.
>
> A device with multitouch capability gains a TouchClass, which describes
> how many touchpoints can be active at one time, as well as how to
> interpret them (axis ranges, rel/abs, etc).  Individual touchpoints
> are described as TouchInfos, which maintain the touch ID, an ephemeral
> tool ID, and the current state of all axes.  TouchInfos are created with
> the first event from that touchpoint, and destroyed when the last event
> has been delivered.

Seems that point was accepted by the people that were here.

>
> Touch events are not affected by keyboard/pointer grabs[0]; a device
> which is actively grabbed for core/Xi events will still send touch
> events.  There are two focus modes (passed to
> InitTouchClassDeviceStruct) to play with: with Relative (the default),
> all touch events are focussed by the device's sprite, but Absolute will
> focus each touchpoint at the window it's in.

idem

>
> During a touchpoint's short lifetime, all motion events will be sent to
> one client and one client only.  Only TouchBegin rather than TouchMotion
> events can be selected for or grabbed, and akin to ButtonPress, only one
> client per window can select for TouchBegin events.  Once a delivery has
> been made to a client without a synchronous grab, all TouchMotion events
> and the TouchFini event will be sent to the same client.

It seems to me, that for feedback reasons, Peter suggested to send the 
events in case of a passive grab to all the stack of clients (2 seemed 
to be the common case) and not to only one: the underlying clients can 
start gesture recognition, early feedbacks even if they know that this 
particular touch may not be their but will be retained by the Window 
Manager.

That's all I wanted to add. :-)

Cheers,
Benjamin

>
> Clients who receive TouchBegin events through synchronous grabs have two
> options for AllowEvents: ReplayTouch (continue attempting delivery from
> the next window in the stack), or AcceptTouch (unfreeze, receive all
> further events for that touchpoint).
>
> I'd appreciate any comments or review, especially from toolkit people.
> I've been testing with a uinput-based 'touchscreen' which provides 3
> independent abs contact points, as well as a Magic Mouse.  Note if
> you're using a Magic Mouse that the kernel driver is buggy: it's
> supposed to send SYN_REPORT ->  SYN_MT_REPORT ->  SYN_REPORT stream to
> indicate that there are no more touchpoints left, but doesn't do so, so
> you get ghost touchpoints hanging around.
>
> Many thanks go to Nokia for sponsoring this work, as well as to Peter,
> Benjamin, Bradley, Chase, Denis, and others for review and assistance.
>
> Cheers,
> Daniel
>
> [0]: Actually, in the current implementation, they will still get
>       frozen while the device is actively grabbed for core/Xi events.
>       It might be possible to skip that, but it would make emulating
>       core/Xi motion events from touch events nigh on impossible.
>
>
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel