multi-touch-dev team mailing list archive

[Chase Douglas <chase.douglas@xxxxxxxxxxxxx>]

Hi all,

Remember when I said the kernel interface for multitouch is all rather
stable and good? Well, it turns out that there is a new proposal to
modify it [1]. I had not been following the linux-input mailing list
where it is being discussed, but I am now :). Here's a summary of the
proposal:

Currently, any time a single property of a single multitouch event (say
the pressure of one touch) changes, all of the current multitouch data
is sent again. If you have 10 fingers touching a screen, this will
generate a lot of data. The problem is that since there is no mechanism
to tell the userspace which touch changed, we have to send all the data
again. It would also be nice to have more explicit touch tracking
exposed through the kernel <-> userspace interface.

The proposal is to send ABS_SLOT events to distinguish between touches.
The kernel and the userspace layers will maintain state for the input
device. When one property of a touch changes, the kernel will explicitly
send an ABS_SLOT event to describe which "slot" (i.e. which touch) the
property change refers to. Slots will have a dynamically generated ID
assigned to them when a touch begins, and the ID will be relinquished
for reuse when a touch ends.

Note that all this depends on the driver supporting touch tracking. For
drivers that do not support touch tracking, the current protocol will be
used (no ABS_SLOT events, and all data sent anytime one piece of data
changes).

Peter Hutterer, one of the X.org maintainers, has been following the
discussion, so hopefully the new protocol will be integrated into any
current X.org multitouch work.

There have been a few revisions of patches to implement this support, so
it appears that it could be committed to the linux-input tree sometime
soon. However, it will not land in 2.6.35, which is the kernel we will
ship with 10.10. If we are inclined, we can look into backporting the
patch into our Maverick kernel. However, since the protocol is not
backwards compatible, we will need to ensure we provide all the proper
support in userspace for both use cases where touch tracking is and is
not provided by the driver.

P.S.: As the multitouch list seems to be private, I'm only CC'ing the
internal kernel team list.

-- Chase

[1] http://www.spinics.net/lists/linux-input/msg08835.html