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

[Henrik Rydberg]

Peter Hutterer wrote:
> On Tue, Jun 22, 2010 at 02:21:59PM +0200, Henrik Rydberg wrote:
>> Peter Hutterer wrote:
>>> On Fri, Jun 18, 2010 at 09:41:01AM +0200, Henrik Rydberg wrote:
>>>> Peter Hutterer wrote:
>>>> [...]
>>>>>> 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?
>>>> You sit at a coffee table, coated with the finest multitouch film there is. You
>>>> put down the tea cup and leave for the restroom, taking the btwallet with you.
>>>> As everybody knows, once the btwallet is off the table, you are logged out. You
>>>> come back, log in. Did anyone drink from your cup?
>>> Interesting example but I can't quite map it to the technical
>>> implementation. We don't have a notion of "logged out", at our level the
>>> tea cup would continue to produce touch points (or not, if lifted off).
>>> Even someone drinking out of it with a straw is covered by the change in
>>> pressure.
>>>
>>> "did anyone drink" is IMO too contextual that we can deal with it at our
>>> level. we can only say "yes, the cup was lifted off" or "the cup is lighter
>>> now". 
>>>
>>> still not quite sure what that information could be.
>> Hehe, well, the example illustrates that if every new touch gets a unique
>> tracking id, one can use that information to determine "newness" over extended
>> periods of time. The straw trick does not really change that fact.
> 
> I don't think the kernel protocol handles this information though, does it?
> What you're suggesting is hardware identification over time that allows you
> to _identify_ a touchpoint repeatedly, even if it goes away and comes back.
> the ABS_MT_TRACKING_ID only identifies during a lifecycle and I understand
> lifecycle as the one until the destruction of the touchpoints.

What you describe sounds more advance than what I had in mind. It could be that
we have slightly different definitions of tracking id. By tracking id, I mean a
sequential number assigned to each new contact. What I was trying to illustrate
was the difference between the two properties is_touch and tracking_id when
applied to slots. In the former case, lifting the cup and putting it back again
may very well result in the exact same state as before. In the latter case,
there will be a difference in the value of the tracking_id.

> If you have hardware that can differ between "tea cup", "right thumb",
> "nose", then you need to export this information as well, something like
> ABS_MT_IDENTIFIER or ABS_MT_LABEL or so.
> 
> So for the example above, the answer to your question "did anyone drink in
> my cup" would be:
> (old_identifier == new_identifier && old_tracking_id != current_tracking_id)
> 
> the interesting bit will then be how to supply actual information in these
> identifiers/labels, since the content can essentially be arbitrary.
> 
> Am I misunderstanding something here?

I am seeing the tracking id in there, so this looks like an example similar to
what I had in mind, only with one additional complication taken into account.

Cheers,
Henrik