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: <CAGS+omA-PwoM=U3xP_Gtadaow9SGt555NPWor_-HuvVE8-R3MQ@mail.gmail.com>
Date:	Fri, 20 Jul 2012 01:05:30 +0800
From:	Daniel Kurtz <djkurtz@...omium.org>
To:	Chase Douglas <chase.douglas@...onical.com>
Cc:	"Chung-Yih Wang (王崇懿)" 
	<cywang@...gle.com>, Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Henrik Rydberg <rydberg@...omail.se>,
	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 Fri, Jul 20, 2012 at 12:16 AM, Chase Douglas
<chase.douglas@...onical.com> wrote:
>
> On 07/18/2012 08:02 PM, Chung-Yih Wang (王崇懿) wrote:
>>
>> Hi Chase,
>>
>>     Thanks for your great comments. You are right, it is impossible to
>> get  correct finger tracking if both fingers are moving. However, we
>> think it still worth to have the firmware tracking of the fingers as
>> they could perform well for most one-stationary-one-moving cases. This
>> will be good enough for the one-stationary-one-moving gestures we want
>> to provide on Cr-48. And that's why we want to make the patch specific
>> to Cr-48.
>
>
> Can you provide more details on what you are attempting to accomplish?

The Cr-48 profile sensor is also a Clickpad.  Thus, one of the most
common user gestures is to click the pad with one finger (to start a
selection) and then swipe a second (almost always "upper") finger
across the pad to extend the selection (or move a selected object).

The semi-mt approach is breaking down when the swiping finger moves
horizontally and "crosses over top" of a lower "stationary" finger.
For example, if a user clicks their finger in the bottom center of the
pad, and while using a second finger to horizontally extend a
selection, the fingers cross in the X direction.

As the moving finger approaches the same X coordinate as the
stationary finger, the reported position of the bottom finger will
start to move significantly towards the upper finger due to a
"pulling" affect of the profile sensor.  Thus, that bottom, stationary
finger starts to move towards the finger that is actually moving.
Eventually, when the moving finger gets close enough to the stationary
finger, the reported X coordinate of the two fingers becomes the same
- the two fingers' reported X coordinates "merge".  As the moving
finger continues to move towards, over and past the lower finger, the
reported position of the two fingers moves together, until the moving
finger gets significantly far enough away (in X) from the lower
finger, at which point the lower finger's reported position starts
moving back to its actual position.

Due to this effect, when using semi-mt, it is very difficult to know
at which point the "finger pattern" of the bounding box changes; in
other words, when the fingers change from "BottomLeft / TopRight" to
"BottomRight / TopLeft".  It can be approximated by assuming that the
"finger pattern" changes when the merged X coordinate passes over the
original starting point of the bottom finger.  However, this
approximation only holds when the bottom finger is perfectly
stationary.  In the real world, the bottom finger rolls/wiggles or
otherwise moves, causing the actual crossing point to change.  Or, as
is also likely, the lower finger is already being pulled when the
upper finger starts moving, so its reported position is already not at
the correct crossing point.  Thus, using semi-mt with this profile
sensor clickpad, we have not been able to generate smooth pointer
motion when an upper finger crosses a lower finger.

What we found, though, is that the firmware does do a much better job
of tracking such horizontal crosses.  Therefore, we would like to get
this raw data from the kernel.  It is trivial for userspace to convert
the raw finger position data to a bounding box format for use with
other gestures.

In any case, we really aren't that familiar with how other "synaptics
semi-mt-compatible" touchpads work.  Using this patch may or may not
be better than semi-mt.  Or, their firmware may or may not follow the
same "always report upper finger in sgm" rule (we have seen other
Synaptics trackpads that do "always report oldest finger in sgm").
This is why we chose to isolate this change to just one hardware type,
so that the change, which improves the experience of a Cr-48 user, has
no deleterious affect on users of any other hardware.

If others try this method with their hardware and it works for them,
then great!   We would be happy to help review additional patches that
extend it to additional systems.

-Daniel

> The only thing you can't do easily with semi-mt is:
>
> * Rotations (but the hardware can't do it anyway, so this is moot)
> * Pinch directions at 45 degree angles (i.e. (pinch up and left, down and
> right) or (pinch down and left, up and right))
>
> You should be able to do everything else with semi-mt, such as pinch
> horizontally vs pinch vertically, movement, etc.
>
> The pinch directions at 45 degree angles could be possible with the Cr-48
> trackpad, but I would want to know that there's a real use case for it
> before undertaking an effort to support it.
>
> -- 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ