linux-kernel - Re: [PATCH 6/8 v3] 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]

Message-ID: <20110812215253.GB9124@polaris.bitmath.org>
Date:	Fri, 12 Aug 2011 23:52:53 +0200
From:	"Henrik Rydberg" <rydberg@...omail.se>
To:	Daniel Kurtz <djkurtz@...omium.org>
Cc:	chase.douglas@...onical.com, dmitry.torokhov@...il.com,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	olofj@...omium.org, chris@...bagwell.com
Subject: Re: [PATCH 6/8 v3] Input: synaptics - process finger (<=3)
 transitions

Hi Daniel,

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

I appreciate the complexity of the protocol at hand, and the patch is
doing an excellent job documenting it. However, it does constitute a
fair deal of code... What about the statements below:

1. When two subsequent sgm packets report the same number of fingers
(and unless told otherwise in some other fashion?), the sgm and the
previous agm contains data for the same fingers as the previous (agm,
sgm) pair, i.e., there is no transition.

2. There is no general way to know which fingers are being reported
after a transition.

If both points above are true, how about something like this:

a) Always report slots zero and one (for two or more fingers)

b) Keep a global number, trackid

c) Parse are buffer agm

d) Parse sgm

e) If a transition occured, increase trackid by two

f) Set TRACKING_ID to trackid in slot zero and trackid+1 in slot one.

It seems to me the above will result in contiuous handling of two
unknown contacts in between transitions, and during transitions, new
contacts will be generated.

The algorithm above could possibly be improved for the 2->1
transition, but from what I gather, 1->2 and 2->3 as well as 3->2 does
not seem to be generally solvable, hence resulting in the above
anyways.

If any of points 1 and 2 are wrong, I am sure you will
enlighten/remind me. ;-)

Cheers,
Henrik
--
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/