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:	Fri, 21 May 2010 00:48:40 +0200
From:	Henrik Rydberg <rydberg@...omail.se>
To:	Ping Cheng <pinglinux@...il.com>
CC:	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>,
	Peter Hutterer <peter.hutterer@...-t.net>,
	Benjamin Tissoires <tissoire@...a.fr>,
	Stephane Chatty <chatty@...c.fr>,
	Rafi Rubin <rafi@...s.upenn.edu>,
	Michael Poole <mdpoole@...ilus.org>
Subject: Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

Ping Cheng wrote:
> On Thu, May 20, 2010 at 12:08 AM, Henrik Rydberg <rydberg@...omail.se> wrote:
>> Hi Ping,
>>
>> first out, thank you for your detailed analysis, it aids in removing ambiguities
>>  and defining the borders of the protocol.
> 
> Glad to hear from you directly this time :). I have more questions.
> 
>> It helps to think of both TRACKING_ID and BLOB_ID as labels of a single
>> identified contact which occupies one slot.
> 
> I need double check with you although I think I know the answer. From
> your explanation and examples so far, I see MT_SLOT is only associated
> with one (x,y). Is this true?  If yes, can we eliminate the
> requirement for TRACKING_ID? If you think the requirement is
> necessary, can you give me an example where missing the TRACKING_ID
> would bring issue or confusion?

Yes, each slot can only be associated with one (x, y) pair. No, we cannot
disregard the tracking id. A slot tracks a single contact for its entire
lifetime, during which the tracking id serves no purpose, but the slot cannot
tell us when the contact is replaced by a new one. This information is carried
by the tracking id.

> 
>> To represent a set of contacts as an
>> entity, one needs to add a label to the slot, representing that entity.
> 
> Doesn't MT_SLOT itself serves as a label? It has a value.  May be
> ABS_MT_SLOT_ID fits the term more closely.

The slot id tells which slot is currently being modified, and carries no
information about the slot itself. To represent a relation between different
contacts, a value representing that relation needs to be added to the event
stream, there is no doubt about that. The BLOB_ID is such a label, and there
will likely be others in the future as well.

> 
>> As pointed out in a later reply by Peter, the BLOB_ID serves this purpose well. The
>> name is slightly unfortunate, being a bit too generic. Let us use this
>> discussion to pin down a more exact definition:
>>
>> ABS_MT_BLOB_ID is a label which groups contacts in close relation to each other,
>> such as a hand.
> 
> I think I get this part.  However, (too late to regret that you've
> replied to me :)
> 
>> With this in mind, the sequence becomes
>>
>> SYN_MT_SLOT 0
>> ABS_MT_BLOB_ID 11
>> ABS_MT_TRACKING_ID 45
>> ABS_MT_POSITION_X x[0]
>> ABS_MT_POSITION_Y y[0]
>> SYN_MT_SLOT 1
>> ABS_MT_BLOB_ID 11
>> ABS_MT_TRACKING_ID 46
>> ABS_MT_POSITION_X x[1]
>> ABS_MT_POSITION_Y y[1]
>> SYN_MT_SLOT 2
>> ABS_MT_BLOB_ID 11
>> ABS_MT_TRACKING_ID 47
>> ABS_MT_POSITION_X x[2]
>> ABS_MT_POSITION_Y y[2]
>> SYN_MT_SLOT 3
>> ABS_MT_BLOB_ID 89
>> ABS_MT_TRACKING_ID 30
>> ABS_MT_POSITION_X x[3]
>> ABS_MT_POSITION_Y y[3]
>> SYN_REPORT
> 
> I would think something like the following would make sense too:
> 
> ABS_MT_BLOB_ID 11
> ABS_MT_TRACKING_ID 45
> ABS_MT_SLOT_ID 0
> ABS_MT_POSITION_X x[0]
> ABS_MT_POSITION_Y y[0]
> ABS_MT_SLOT_ID 1
> ABS_MT_POSITION_X x[1]
> ABS_MT_POSITION_Y y[1]
> ABS_MT_SLOT_ID 2
> ABS_MT_POSITION_X x[2]
> ABS_MT_POSITION_Y y[2]
> SYN_MT_BLOB
> ABS_MT_BLOB_ID 89
> ABS_MT_SLOT_ID 3
> ABS_MT_TRACKING_ID 30
> ABS_MT_POSITION_X x[3]
> ABS_MT_POSITION_Y y[3]
> SYN_MT_BLOB
> SYN_REPORT
> 
> where we have two blob of data. They represent finger 1 and finger 2.
> Finger 1 has a tracking number 11 while finger 2 has 30.  We do not
> track the three contacts inside the blob since they all belong to the
> same finger.  We could even combine type A and B as:

Well, the way the protocol is defined, SYN_MT_BLOB does not exist, and any
attribute change outside the slot id context simply has no meaning.

> 
> ABS_MT_TRACKING_ID 0      # indicates first finger or hand
> ABS_MT_BLOB 3                     # indicates 3 contacts in the blob
> ABS_MT_POSITION_X x[0]
> ABS_MT_POSITION_Y y[0]
> SYN_MT_REPORT
> ABS_MT_POSITION_X x[1]
> ABS_MT_POSITION_Y y[1]
> SYN_MT_REPORT
> ABS_MT_POSITION_X x[2]
> ABS_MT_POSITION_Y y[2]
> SYN_MT_REPORT
> ABS_MT_TRACKING_ID 1      # indicates second finger or hand
> ABS_MT_BLOB_ID 1               # indicates 1 contact in the blob
> ABS_MT_POSITION_X x[3]
> ABS_MT_POSITION_Y y[3]
> SYN_REPORT
> 
> where SYN_MT_BLOB is unnecessary since we know how many contacts we
> are going to get. I would expect this approach complicates the
> implementation in the kernel. So I am not sure if it makes sense to
> use it or not.  Just to share some random thoughts with you.

Thank you for your random suggestions.

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/