On Thu, Jul 07, 2011 at 12:41:26AM +0800, Daniel Kurtz wrote: > On Wed, Jul 6, 2011 at 3:27 AM, Henrik Rydberg <rydberg@xxxxxxxxxxx> wrote: > >> ... > >> This implementation addresses the following issues: > >> > >> (1) Improves handling of the 2-finger case. Image sensors due allow > >> true MT-B for two finger case. This, for example, allows detecting > >> whether the click in a click+drag is happening in bottom right or > >> bottom left quadrant of the pad. > > > > In principle, this could be done within the semi-mt realm by adding a > > binary value to the protocol, distinguishing the diagonals of the > > bounding box. It would be ugly too, but at least it would be > > compatible with the current semi-mt effort in userspace. > > (A) I think the "semi-mt" protocol works like this: > (1) When two or more fingers are on the pad, report two MT-B slots, where: > (a) slot[0] contains (x_min, y_min) of the two fingers > (b) slot[1] contains (x_max, y_max) of the two fingers > (c) Total number of fingers on pad is indicated by EV_KEY/BTN_TOOL_* is set. > (2) If one of the two fingers is removed, then the first slot is > used to report > the remaining finger, whichever it is, without changing the > slot's tracking_id. > (3) Advertise this behavior with the SEMI_MT device property > > (B) This is what the proposed T5R2 driver does: > (1) When N fingers are on the pad, report N MT-B slots, where: > (a) The lowest indexed active slot (tracking_id != -1) contains > valid finger position data. > (b) The highest indexed active slot (tracking_id != -1) contains > valid finger position data. > (c) Any active slots (tracking_id != -1) between these does not > contain valid finger position data, these 'hidden' slots are just > active to indicate that there are that many fingers on the pad. > (d) Total number of fingers on the pad is always the number of active slots. > (2) When fingers are removed from the pad: > (a) keep reporting the fingers that are left in the same slots, > with the same tracking_ids, if possible. > (b) If the identities of the fingers that remain is ambiguous, > invalidate all slots,then re-assign the fingers that remain to new > slots, with new tracking ids. > (3) Advertise this behavior with the T5R2 device property > This is a no-go. I do not want to add TxRy or similar "properties". We have a workable semi-mt (counding box) and full mt concepts and we should present userspace with data stream that conforms either one or another. > (C) A third, compromise implementation might be to do something like this: > (1) When >=2 fingers are on the pad, report 2 MT-B slots, where: > (a) slot[0] reports finger 1 > (b) slot[1] reports finger 2 > (c) Total number of fingers on pad is indicated by EV_KEY/BTN_TOOL_* is set. > (2) If 1 finger is removed, the tracking_id for its slot is invalidated; > but, the finger that remains stays in its same slot with the > same tracking_id. > (3) Whenever the number of fingers changes from/to 3 or more > fingers, both slots are always invalidated. > New tracking_ids are assigned to both slots which contain the > two fingers now being reported. > (4) No special driver property is required for this, not even "semi-mt". > It should be as pure MT-B as we can get (plus BTN_TOOL_* hack). > This is the best option in my opinion. We will present 2 finger position data plus extended finger count. Thanks. -- Dmitry -- 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
