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