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

Benjamin Tissoires tissoire at cena.fr
Thu Jun 17 23:46:17 PDT 2010

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 ?

>>> 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.

>> 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.


>> 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.

More information about the xorg-devel mailing list