[PATCH evdev 0/3] Preliminary support of multitouch (rev4)

[Benjamin Tissoires]

Le 18/06/2010 08:53, Peter Hutterer a écrit :
> On Fri, Jun 18, 2010 at 08:46:17AM +0200, Benjamin Tissoires wrote:
>> Le 18/06/2010 06:56, Peter Hutterer a ?crit :
>>> On Fri, Jun 18, 2010 at 12:18:00AM -0400, Rafi Rubin wrote:
>>>> On Thu, Jun 17, 2010 at 11:51:34AM -0400, Chase Douglas wrote:
>>>>> On Thu, 2010-06-17 at 12:16 +1000, Peter Hutterer wrote:
>>>>>> On Thu, Jun 10, 2010 at 05:47:57PM +0200, Benjamin Tissoires wrote:
>>>>>>> Even if there is an interesting thread concerning the use of
>>>>>>> multitouch on xorg-devel,
>>>>>>> I still send the up-to-date patches to enable multitouch as valuators.
>>>>>>>
>>>>>>> Changes since last time:
>>>>>>>
>>>>>>> * Remove the detection of the maximum number of touches based on the
>>>>>>> tracking ID
>>>>>>> * changes in comments
>>>>>>
>>>>>> Henrik, Rafi, others - any further comments on this? Patches look good
>>>>>> to
>>>>>> me, with a minor issue (see below) that can be fixed in a follow-up
>>>>>> patch.
>>>>>
>>>>>>  From patch 2/3:
>>>>>          +#define ABS_MT_X_VALUE   0x8
>>>>>          +#define ABS_MT_Y_VALUE   0x16
>>>>> It looks like ABS_MT_Y_VALUE should be 0x10.
>>>>
>>>> :)
>>
>> Peter, would you correct it ?
>
> sure.
>
>>>>
>>>>> Overall this makes sense to me for devices where the MT data should be
>>>>> attached to the cursor (i.e. like a magicmouse). How will this mesh with
>>>>> direct input devices (or whatever mechanism is developed for multitouch
>>>>> touchscreens)? It seems to me we will need to somehow tell the module
>>>>> whether to pass the data as valuators or as DIDs, but not both. However,
>>>>> that's an implementation detail that can be worked out later when we get
>>>>> to it.
>>>>>
>>>>>> Benjamin - I'm not sure exposing the tracking ID in a valuator is a good
>>>>>> long-term solution. Does it provide any info that we do not already
>>>>>> have by
>>>>>> splitting the touchpoints into different valuators?
>>>>>
>>>>> Why not expose the tracking ID? It's one less thing for the client to
>>>>> worry about if it needs to track touches. Without the ID, clients would
>>>>> have to implement their own tracking algorithms because they would just
>>>>> get an array of touches. The same finger will be sent in a different
>>>>> slot of the array on subsequent events, such as when a previous finger
>>>>> is removed.
>>>>>
>>>>> -- Chase
>>>>
>>>> I believe the argument against is that the valuators already carry that
>>>> information implicitly (eg axis 12 would be Y of the third contact and
>>>> would continue in that role even if there are no
>>>> active contacts 1 and 2).  As such having another valuator would be
>>>> wasteful.
>>>
>>>
>>> yeah, it's superfluous and imo sending what is essentially an ID down an
>>> axis
>>> seems a bit odd at best. It's akin to sending a button number down as an
>>> axis.
>>
>> I agree with you, but only for the protocol that includes MT_SLOTS. As
>> the current patchwork deals with protocol A, and as this protocol
>> consists in a sort of pass-through (don't know if it's the word...) of
>> the device events, I think we should also send the trackingID.
>> When slots will be available, and the tracking will be done into the
>> kernel (or in mtdev), and Xinput2 masks will be available, we could just
>> drop the trackingID. But currently, for me, it's the only one solution
>> regards to the set of patches, as there is no tracking.
>>
>> Let's have en example: the magicmouse. This devices sends the touches in
>> order from the lowest to the highest, even if the contact 2 is newer
>> than the contact 4. With this current implementation, and without the
>> trackingID, the client will see the contact 4 jumped to where is the new
>> contact 2, and creates a new one to the old position of contact 4.
>
> why don't you work around this in the evdev driver then? that's the layer that
> should honor the tracking ID and convert it into what's essentially slot
> information.

If I start having states (to keep the link between trackingID and slots) 
into the Xevdev driver, this will conflict with the handling of protocol 
B (the one that will be available soon). That's my biggest and blocking 
point.

>
> I'd also request you have a look at adding the mask bits to the X server input
> APIs. Afaict, this is the only reason we can't do this now and it is quite
> fixable.

will do.

> I don't want any client to rely on the tracking ID in the valuator
> information, not even short term.

Ok, I think you could just apply the patch 1/3 named "Add the names of 
the valuators for the multitouch properties". This patch is totally 
separated of the input handling, but just adds the names.

We can wait a little for Henrik to publish mtdev and then just skip the 
protocol A and directly apply protocol B (with slots and masks available).

Cheers,
Benjamin

>>>> On the other hand, some devices carry a tiny be of extra information
>>>> through the specific contact id's, and they are not strictly the lowest
>>>> set of numbers needed to express the contacts that
>>>> are active or have been activated since the last period of inactivity.
>>> > From what I've heard the magic mouse (again) is one such example.  I
>>>> haven't actually poked around enough to see it.
>>>
>>> do you have any info on what this extra information could be?
>>
>> See above ;) Also, the magicmouse retains the last position of each
>> contact and tries to reuse it when possible.
>>
>> Cheers,
>> Benjamin
>>
>>>
>>>>
>>>> Personally I haven't yet come up with or heard an argument for caring
>>>> about the real tracking id values and every usage case I've come up with,
>>>> it would seem just as easily served computing it
>>> >from in the client.  However, I also know that I'm insufficiently
>>>> creative to eliminate the possibility that someone else would have a good
>>>> reason down the line.  Would it make sense to leave
>>>> it as an option?
>>>>
>>>>
>>>> I'd like to see these patches accepted.  Like Chase, I'm concerned how
>>>> this
>>> will interact with the DID discussion.  Would it make sense to apply it in
>>> a
>>> branch at very least so Ben doesn't have
>>>> to continualy maintain the changes while the discussion rolls on.
>>>
>>> I expect it to provide some useful information once people start playing
>>> with
>>> it. It may not be the final approach but meanwhile, any info we can get on
>>> how
>>> we can handle input better is useful. Besides, the DID implementaion is
>>> quite a
>>> bit off, as far as I can tell.
>>>
>>>
>>