Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Henrik Rydberg <rydberg@euromail.se>]

Peter Hutterer wrote:
[...]
>>> This is confusing me now :)
>>>
>>> How would a device get multiple x/y coordinates for a single contact? I
>>> could understand a range of coordinates but that's what we have the
>>> ABS_MT_WIDTH_MAJOR/MINOR for. If a touchpoint sends two different x/y
>>> coordinates, wouldn't that be two touchpoints, tracked individually and thus
>>> with a different tracking ID?
>>>
>>> I read the example above as _the_ example for using blob IDs to combine
>>> multiple contacts into one semantic contact.
>> As Henrik pointed out, the current BLOB format is for "more generic
>> contact forms", such as rectangles or ellipses.  They are special
>> blobs. A generic (true) blob doesn't have to have a regular shape.  It
>> is most likely in an irregular shape. They would be represented in an
>> array of points/contacts/(x,y)s,  whichever term works for you :).
> 
> Hmm. I always assumed blob is for irregular shapes, and rectangles or others
> are just subsets of irregular shapes (with slightly less 'ir', maybe).
> So what would be the difference between these two event streams?
> 
> ABS_SLOT 0
> ABS_MT_TRACKING_ID 14
> ABS_MT_POSITION_X x[0]
> ABS_MT_POSITION_Y y[0]
> ABS_SLOT 1
> ABS_MT_TRACKING_ID 14
> ABS_MT_POSITION_X x[1]
> ABS_MT_POSITION_Y y[1]
> 
> 
> ABS_SLOT 0
> ABS_MT_TRACKING_ID 14
> ABS_MT_BLOB_ID 1
> ABS_MT_POSITION_X x[0]
> ABS_MT_POSITION_Y y[0]
> ABS_SLOT 1
> ABS_MT_BLOB_ID 1
> ABS_MT_TRACKING_ID 15
> ABS_MT_POSITION_X x[1]
> ABS_MT_POSITION_Y y[1]

I, for one, prefer a third example, but for some other time. I know, the first
example is my fault, but it was created to illustrate that it is possible, not
that it is a particularly good idea. :-)

For type A devices, in the absence of identifiable contacts, there is room for
geometrical groupings of different kinds. Since all data is transferred between
synchronization points, the ABS_MT_BLOB_ID serves this purpose well.

However, for type B devices, seeking to reduce bandwidth by adding the concept
of identifiable contacts, it does not make sense to send overly detailed data.
If anything, the shape of a contact should be communicated in a simpler way,
maybe by extending the ABS_MT_TOOL_TYPE list.

Here is an attempt to capture the above constraints in the documentation:

@@ -244,15 +244,16 @@ MT_TOOL_PEN [2].
 ABS_MT_BLOB_ID

 The BLOB_ID groups several packets together into one arbitrarily shaped
-contact. This is a low-level anonymous grouping, and should not be confused
-with the high-level trackingID [5]. Most kernel drivers will not have blob
-capability, and can safely omit the event.
+contact. This is a low-level anonymous grouping for type A devices, and
+should not be confused with the high-level trackingID [5]. Most type A
+devices do not have blob capability, so drivers can safely omit this event.

 ABS_MT_TRACKING_ID

 The TRACKING_ID identifies an initiated contact throughout its life cycle
-[5]. There are currently only a few devices that support it, so this event
-should normally be omitted.
+[5]. This event is mandatory for type B devices. The value range of the
+TRACKING_ID should be large enough to ensure unique identification of a
+contact maintained over an extended period of time.

Henrik