[RFC] Multitouch support, step one
Benjamin Tissoires
tissoire at cena.fr
Wed Mar 17 11:58:08 PDT 2010
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
More information about the xorg-devel
mailing list