Input: synaptics - process finger (<=3) transitions

Input: synaptics - process finger (<=3) transitions

Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:

 * When there are 3 or more fingers, only two are reported.
 * The touchpad tracks the 5 fingers in slot[0] through slot[4].
 * It always reports the lowest and highest valid slots in SGM and AGM
   packets, respectively.
 * The number of fingers is only reported in the SGM packet.  However,
   the number of fingers can change either before or after an AGM
   packet.
 * Thus, if an SGM reports a different number of fingers than the last
   SGM, it is impossible to tell whether the intervening AGM corresponds
   to the old number of fingers or the new number of fingers.
 * For example, when going from 2->3 fingers, it is not possible to tell
   whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
   3rd finger).
 * When fingers are added one at at time, from 1->2->3, it is possible to
   track which slots are contained in the SGM and AGM packets:
     1 finger:  SGM = slot[0], no AGM
     2 fingers: SGM = slot[0], AGM = slot[1]
     3 fingers: SGM = slot[0], AGM = slot[2]
 * It is also possible to track which slot is contained in the SGM when 1
   of 2 fingers is removed.  This is because the touchpad sends a special
   (0,0,0) AGM packet whenever all fingers are removed except slot[0]:
     Last AGM == (0,0,0): SGM contains slot[1]
     Else: SGM contains slot[0]
 * However, once there are 3 fingers, if exactly 1 finger is removed, it
   is impossible to tell which 2 slots are contained in SGM and AGM.
   The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
 * Similarly, if two fingers are simultaneously removed (3->1), then it
   is only possible to know if SGM still contains slot[0].
 * Since it is not possible to reliably track which slot is being
   reported, we invalidate the tracking_id every time the number of
   fingers changes until this ambiguity is resolved when:
     a) All fingers are removed.
     b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
     c) All fingers are removed except slot[0].  In this special case, the
        ambiguity is resolved since by the (0,0,0) AGM packet.

Behavior of the driver:

When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad.  If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.

The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
 a) There are more than 2 fingers on the pad.
 b) During ambiguous number-of-fingers transitions, the correct track_id
    for one or both of the slots cannot be determined, so the slots are
    invalidated.

Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>