[RFC] Multitouch proposal v2 + implementation
daniel at fooishbar.org
Sun Sep 19 21:45:59 PDT 2010
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.
Touch events are not affected by keyboard/pointer grabs; 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.
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.
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.
: 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the xorg-devel