lkml.org 
[lkml]   [2010]   [May]   [20]   [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)
Ping Cheng wrote:
> On Thu, May 20, 2010 at 12:08 AM, Henrik Rydberg <rydberg@euromail.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



\
 
 \ /
  Last update: 2010-05-21 00:51    [W:0.153 / U:1.428 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site