On Mon, Sep 10, 2012 at 09:31:52PM +0800, Daniel Kurtz wrote:
On Mon, Sep 10, 2012 at 8:47 PM, Seth Forshee [off-list ref]wrote:
quoted
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.
quoted
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
On Mon, Sep 10, 2012 at 10:29 PM, Seth Forshee
[off-list ref] wrote:
On Mon, Sep 10, 2012 at 09:31:52PM +0800, Daniel Kurtz wrote:
quoted
On Mon, Sep 10, 2012 at 8:47 PM, Seth Forshee
[off-list ref]wrote:
quoted
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.
quoted
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.
quoted
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?
Sorry I was confusing, but you answered already:
* If the unknown position is near "max", then 8176 (0x1ff0) is reported.
* If the unknown position is near 0, then 0 is reported, so no fear
that we would warp from 0 -> 8176 if the TP lost track of the finger.
Reviewed-by: Daniel Kurtz <redacted>
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.
quoted
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