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

[Peter Hutterer]

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.
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?
 
Cheers,
  Peter