linux-kernel - Re: [PATCH 7/9 v4] Input: synaptics - process finger (<=3) transitions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 18 Aug 2011 09:02:44 -0700
From:	Chase Douglas <chase.douglas@...onical.com>
To:	Daniel Kurtz <djkurtz@...omium.org>
CC:	dmitry.torokhov@...il.com, rydberg@...omail.se,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	olofj@...omium.org, chris@...bagwell.com
Subject: Re: [PATCH 7/9 v4] Input: synaptics - process finger (<=3) transitions

On 08/18/2011 04:28 AM, Daniel Kurtz wrote:
> 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@...omium.org>

Acked-by: Chase Douglas <chase.douglas@...onical.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/