> > I guess the real question here is: do the following patches really > > help? Creating additional logic to band-aid yet another special case, > > which still does not give full MT support, seems to create more > > problems than it solves. If the code was needed to ensure proper five > > finger support to userspace, then maybe one could live with > > it. However, as it stands, keeping the semi-mt behavior also for the > > slightly better devices may not be such a bad idea, after all. > > > > _Iff_ the whole series can be formulated as true protocol B support > > (no special flags, please), and _iff_ it helps to use software finger > > tracking for less than four fingers, then please do tell, and we can > > add that part to the input core to simplify the synaptics > > implementation a bit. > > Image sensors and profile sensors behave differently. However, even > the image sensors do not allow true MT-B, since they only report 2 > fingers. Hence, it makes sense to add a property to distinguish the 3 > cases. The lifetime of such a solution should also be considered. > 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. > (2) Helps improve handling of number-of-fingers transitions. Most > of the complexity of the synaptics driver comes with dealing with the > complicated way that the protocol handles number-of-fingers > transitions. Just ignoring them with semi-mt could cause lots of > jumpy behavior as the transitions are mapped to bounding boxes whose > coordinates jump around. Thus, this implementation tries to notify > userspace of finger transition by 'rolling slots' when necessary. If the kernel driver cannot create a smooth bounding box, which by all means is simpler than providing proper finger tracking, then there is no way this can be done in userspace either. > What I mean is, if the driver deduces that a given slot may not > contain the same finger as a previous report, it releases it (sets its > tracking_id = -1), and reestablishes the slot with a new tracking_id > when it is more confident that it is now tracking a new finger. As a general question, one might ask oneself: If the new device _really_ can track five fingers, then why does it not send enough information to recover that information? A proper tracking id would suffice. > (3) Properly decode the "AGM_CONTACT" packet type. 4- and 5- finger > gestures may never be supported, however, I think it is still a good > idea to detect and parse these packets properly in the kernel driver, > and leave policy to userspace. I'm open to alternative suggestions > for ways to represent this to userspace. The idea in this patch set > is to reuse the MT-B plumbing as much as possible, but use the device > property to mark the fact that the interpretation of the resulting > slots is somewhat different. If the data cannot be reliably utilized, I doubt anyone cares. There is a lot of hardware out there capable of tracking ten and more fingers, without the agonizing pain. > A bare minimum patchset might do: > (1) Do true MT-B for two fingers > (2) Improved number-of-finger tracking for just the 2-finger case. > (Keep tracking finger 1 when finger 2 is removed, and vice versa) In what way is this different from 1)? > (3) Properly parse, but don't use, AGM_CONTACT packets I am tempted to write something about Schrödinger's cat here... ;-) Thanks, 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
