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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
