On Mon, Sep 10, 2012 at 10:29 PM, Seth Forshee <seth.forshee@xxxxxxxxxxxxx> wrote: > > 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@xxxxxxxxxxxxx>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? 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 <djkurtz@xxxxxxxxxxxx> > > 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
