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.
- Protocol: no protocol changes are necessary, though care must be taken in
regards to XI1 clients.
Although the XI2 protocol does allow device changes, this is not specified
in the XI1 protocol, suggesting that once a device changes, potential XI1
clients should be either ignored or limited to the set of axes present
when they issued the ListInputDevices request. Alternatively, the option
is to just encourage XI1 clients to go the way of the dodo.
Corner cases:
We currently have a MAX_VALUATORS define of 32. This may or may not be
arbitrary and interesting things may or may not happen if we increase that.
another problem - no ability to do "pressure" here. ie have each touch point
have a radius for example (x and y radius) etc. etc. ??? what happened to that?
The kernel's MT API caters for width/height, orientation and a few other
things (see linux/input.h, essentiall, we're just mirroring here anyway).
what it doesn't cater for yet is MT pressure though IIRC I've either seen a
patch float past or at least the talk about it. Since we only need to add
another label, that's easy enough. But good point, we mustn't forget this.
Currently, we don't aim at modifying the data the device send. If it
provides a pressure (starting from kernel 2.6.33 I think), we should
transfer it to the client. But, I don't think we should create an
arbitrary value depending on sizeX and sizeY.
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_*.
Cheers,
Benjamin
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
