Re: [PATCH] Input: synaptics - Adjust threshold for treating position values as negative

[Seth Forshee <seth.forshee@canonical.com>]

On Mon, Sep 10, 2012 at 09:31:52PM +0800, Daniel Kurtz wrote:
> On Mon, Sep 10, 2012 at 8:47 PM, Seth Forshee <seth.forshee@canonical.com>wrote:
> 
> > Commit c039450 (Input: synaptics - handle out of bounds values from the
> > hardware) caused any hardware reported values over 7167 to be treated as
> > a wrapped-around negative value. It turns out that some firmware uses
> > the value 8176 to indicate a finger near the edge of the touchpad whose
> > actual position cannot be determined. This value now gets treated as
> > negative, which can cause pointer jumps and broken edge scrolling on
> > these machines.
> 
> 
> > I only know of one touchpad which reports negative values, and this
> > hardware never reports any value lower than -8 (i.e. 8184). Moving the
> > threshold for treating a value as negative up to 8176 should work fine
> > then for any hardware we currently know about, and since we're dealing
> > with unspecified behavior it's probably the best we can do. The special
> > 8176 value is also likely to result in sudden jumps in position, so
> > let's also clamp this to the maximum speicified value for the axis.
> >
> 
> Would 8176 still be reported if it was near the X/Y_MIN edge but cannot be
> determined?

I've been told 0 is reported in that case.

> If we just report MAX, will that warp the position all the way across the
> pad?

I don't follow. How would this have any impact on the other positions?

The only place where I'd expect to see some sort of impact is
immediately above or to the left of the location where the touchpad
starts reporting this value. Reporting MAX seems more reasonable to me
than reporting 8176, since the adjacent position is almost certainly
nowhere near 8176. An argument could be made for using the bezel limits
instead, which probably would be better for devices conforming to the
published documentation, but then we know that some devices operate
outside of these parameters.

Or we could just go back to reporting 8176 directly, which is what we
were doing before my previous patch.

> If this behavior gets too bizarre, instead of making this "one size fits
> all" solution, is it possible to use some quirks?  I recently added a patch
> that reads the board_id for the synaptics pads - we could use this to
> identify a particular type of pad and handle it appropriately.

That could make sense for the touchpad that reports negative values, as
this appears to be a problem isolated to one or a very small number of
machines.

But I've had reports of multiple machines reporting 8176, two of which
I've confirmed and one of which is almost certainly the same issue.
These are all Asus machines, but different models. There's also a report
on an Acer machine that could be the same thing, but it's far less
certain. The bug reports are coming from a 3.2-based kernel, so I don't
have the board and firmware ids printed in dmesg.

Seth