[RFC] Multitouch support, step one

[Benjamin Tissoires]

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