[RFC] Multitouch support, step one

[Michael Poole]

Peter Hutterer writes:

[snip]
> Details:
> The data we get from the (Linux) kernel includes essentially all the ABS_MT
> events, x, y, w, h, etc. We can pack this data into valuators on the device.
> In the simplest case, a device with two touchpoints would thus send 4
> valuators - the first two being the coordinate pair for the first touch
> point, the latter two the coordinates for the second touch point.

Short comment: There will be more valuators; a max of 32 is not enough.

Long version:

I think this undersells the number of valuators that MT devices will
provide.  I am only really familiar with Apple's Magic Mouse, but I
understand Apple's other MT devices report similar data (except for not
having actual, touch-independent X/Y/button data).  The Magic Mouse has
hardware touch tracking, and reports the orientation, semi-major axis
length, semi-minor axis length, touch area and a state or event bitmask
for each touch.

The tracking ID will probably be the most useful for applications,
followed by touch area (the mouse can report a touch before physical
contact occurs).  I am not sure how gesture recognition would use the
ellipse data, but I am pretty sure that some applications will want
them.  The interpretation of the state/event bitmask is currently
unclear, so it could be reasonably omitted.

With the standard X/Y valuators and buttons as a base, and a likely
desire to emulate vertical and horizontal scroll wheels outside the
application, the Magic Mouse needs ~5 + 7*N valuators for N touches --
with a 32 valuator limit, it will only be able to pass some of the
hardware fields to applications.

So, as a non-X developer, I would like that limit to go up.  Barring
that, I would like some notional plan on what the long-term solution
will look like if the short-term solution involves truncated event
reports.

Michael Poole