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

[Ping Cheng]

On Thu, May 20, 2010 at 12:08 AM, Henrik Rydberg <rydberg@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/