`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 firstexample is my fault, but it was created to illustrate that it is possible, notthat it is a particularly good idea. :-)For type A devices, in the absence of identifiable contacts, there is room forgeometrical groupings of different kinds. Since all data is transferred betweensynchronization points, the ABS_MT_BLOB_ID serves this purpose well.However, for type B devices, seeking to reduce bandwidth by adding the conceptof 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`