lkml.org 
[lkml]   [2010]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)
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



\
 
 \ /
  Last update: 2010-05-24 11:53    [W:0.058 / U:0.624 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site