[RFC] Multitouch support, step one

[Peter Hutterer]

On Wed, Mar 17, 2010 at 07:58:08PM +0100, Benjamin Tissoires wrote:
> Le 16/03/2010 02:58, Peter Hutterer a écrit :
> >>An other point for keeping the valuator trackingID. Some device
> >>(stantum and magicmouse) send a trackingID different than touch
> >>point. i.e. the trackingID is between 1 and 255 on the stantum, and
> >>between 1 and 16 on the magic mouse. I don't know if the user app
> >>should use this, or a higher level id could do the job.
> >
> >the tracking ID can be abstracted away in the driver. In fact, if we chose
> >the valuators to be representative the tracking ID can fall away
> >immediately. i.e. valuator n is _always_ touchpoint m.
> >
> >Of course, if we instead choose to have touchpoints dynamically assigned,
> >then we need to send the tracking ID down the wire as well. I'm not a big
> >fan of this at this point but I can be convinced otherwise.
> 
> I've got an interesting argument to keep the tacking ID. The Magic
> Mouse has a very 'intelligent' algorithm to assign the tracking ID:
> it seems to increment as usual the different tracking IDs, but if
> you release your touch, take a coffee or whatever, and even touch
> other zones of the device; then, when you re-touch the same initial
> zone, you will get the same tracking ID.
> 
> I don't know if I'm enough clear, but this particular device keeps
> the names of the different tracking IDs.
> 
> I don't know either if it will be useful for client applications,
> but it is something to take into account.
> 
> >
> > [snip]
> >
> >>>>>Work needed:
> >>>>>- drivers: updated to parse ABS_MT_FOO and forward it on.
> 
> already started to work on that, to provide a proof of concept (code
> still not published as I need to reorganize parts of it).
> 
> >>>>>- X server: the input API still uses the principle of first + num_valuators
> >>>>>   instead of the bitmask that the XI2 protocol uses. These calls need to be
> >>>>>   added and then used by the drivers.
> 
> as soon as it will be available, I can put it in the piece of
> patches I'm working on. But currently, the workaround I told before
> (packing all mt values at the beginning of the mt segment in
> valuators, and sending tracking ID) is working quite well.

I actually expect this to be the largest change since a fair bunch of code
utilises the first + num approach. All that has to be switched to
masked-based approaches now. This is just a heads-up to not get too
disappointed :)

> >oh, I'm not suggesting modifying the data from the kernel. I'm suggesting
> >to add a label for ABS_MT_PRESSURE in case the kernel will get this in the
> >next revision and the devices will start sending this information. If a
> >device doesn't have it, then we'll never see it anywhere anyway.
> 
> In commit a34812b09000db2ff2a1dc6182602839123edd4e "Add labels for
> multitouch valuators", you made me add ABS_MT_PRESSURE. So it's at
> the same level than any other ABS_MT_*.

I did? 
wow. sometimes I impress myself.
 
Cheers,
  Peter