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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
