linux-kernel - Re: [PATCH v2] Input: synaptics

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] [day] [month] [year] [list]

Date:	Wed, 18 Jul 2012 08:38:20 -0700
From:	Chase Douglas <chase.douglas@...onical.com>
To:	Chung-yih Wang <cywang@...omium.org>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Henrik Rydberg <rydberg@...omail.se>,
	Daniel Kurtz <djkurtz@...omium.org>,
	JJ Ding <dgdunix@...il.com>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] Input: synaptics - use firmware data for Cr-48

On 07/18/2012 03:22 AM, Chung-yih Wang wrote:
> The profile sensor clickpad in a Cr-48 Chromebook does a reasonable job of
> tracking individual fingers. This tracking isn't perfect, but, experiments
> show that it works better than just passing "semi-mt" data to userspace,
> and making userspace try to deduce where the fingers are given a bounding box.
>
> This patch tries to report correct two-finger positions instead of the
> {(min_x, min_y), (max_x, max_y)} for profile sensor clickpads on Cr-48
> chromebooks. Note that this device's firmware always reports the higher
> (smaller y) finger in the "sgm" packet, and the lower (larger y) finger in the
> "agm" packet. Thus, when a new finger arrives on the pad, the kernel driver
> uses a simple Euclidean distance measure to deduce which of the two new fingers
> should keep the tracking ID of the previous single finger. Similarly, when one
> finger is removed, the same measure is used to determine which finger remained
> on the pad.

Can it keep track of the touches as you rotate them past each other in 
both the X and Y axes? If not, then it should remain a semi-mt device. 
Even if you can guess which touch is which when a second touch is added, 
you will lose track of it when the user attempts to perform a rotation.

Semi-mt is our only mechanism for telling userspace that the device 
can't accurately tell us about rotations. We could create a new device 
property to say: "This device kinda sorta tells us enough info usually 
to know where two touches are initially." I don't think the effort is 
worth it though. What is the point of providing the exact locations on a 
trackpad if they can't be used for rotation?

-- Chase
--
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/