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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 24 May 2010 11:49:36 +0200
From:	Henrik Rydberg <rydberg@...omail.se>
To:	Peter Hutterer <peter.hutterer@...-t.net>
CC:	Ping Cheng <pinglinux@...il.com>, Rafi Rubin <rafi@...s.upenn.edu>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Mika Kuoppala <mika.kuoppala@...ia.com>,
	Benjamin Tissoires <tissoire@...a.fr>,
	Stephane Chatty <chatty@...c.fr>,
	Michael Poole <mdpoole@...ilus.org>
Subject: Re: [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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/