Ping Cheng wrote: > 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? 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-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
