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