Re: [PATCH v2] Input: synaptics - use firmware data for Cr-48

[Chase Douglas]

On 07/19/2012 10:05 AM, Daniel Kurtz wrote:
> On Fri, Jul 20, 2012 at 12:16 AM, Chase Douglas
> <chase.douglas@xxxxxxxxxxxxx> 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.

Ok, that's very helpful to know, thanks for providing such a detailed 
response!

So the problem is that you want to support the kernel providing two 
touches, but the touch locations are only valid if they do not cross in 
the Y axis. That's a very nuanced property of the device, one that is 
only specific to certain touchpads from one manufacturer.

I understand the usefulness of this functionality, but I also worry 
about proliferating the number of properties for devices (there are only 
32 bits we can use, IIRC). I see four options off the top of my head:

* Don't do anything, leave it as SEMI_MT. Obviously this would suck, but 
it is an option.

* Make the trackpad advertise itself as *not* SEMI_MT. This would be 
broken, however, if the user performs a rotation where the touches cross 
in the Y axis. I feel this is plain wrong according to the stated 
protocol documentation and previous behavior, so I don't want to do this.

* Add a new device property (INVALID_Y_AXIS_CROSSING?) that describes 
the exact behavior of this device. I would be ok with this if everyone 
else is, but only because proper clickpad behavior (which I consider 
very importand) is broken without this knowledge.

* Leave the device as SEMI_MT, but provide the real locations, and allow 
userspace to determine the device vendor/model/etc. If userspace knows 
that a specific device behaves in a specific way, it can do its own 
quirking handling. Given the specificity of this behavior to only some 
devices of one brand, this would be my suggested resolution to the issue.

-- Chase
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/