lkml.org 
[lkml]   [2010]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)
From
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?

>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.

> 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:

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.

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

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