Comment 361 for bug 606238

Now that Linux 3.9 is making its way into circulation, let's summarize the reported issues to date:

1) No Dolphin V2 support. Still need to borrow hardware to fully understand the report format and make edge scrolling work without excessive pressure. I believe we have a good init sequence.

2) Resync errors:

[1766509.702598] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 6
[1766509.712794] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.
[1766509.722987] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 6
[1766509.733151] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.
[1766509.743293] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 6
[1766509.753533] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.

I see these pop up in dmesg every week or two; they run for maybe a minute or so and then vanish, with no obvious ill effects. Not sure how to reproduce them.

3) Click-and-drag (e.g. selecting text in an xterm) suddenly quits working. I've only seen this happen once. Unloading and reloading psmouse.ko fixed it. This problem mystifies me because when I ran xev, I still saw all of the proper events coming from the input device. So maybe it was caused by something higher in the stack.

4) Tap-to-click is broken on Rushmore[1]. Root cause: when transitioning from Linux 3.8 (touchpad detected as generic PS/2 mouse) to 3.9 (touchpad detected as an ALPS touchpad), tap-to-click in the pointer settings may need to be enabled by hand. If the touchpad is detected as a generic PS/2 mouse, tap-to-click will work regardless of this setting.

5) Pointer jumps all over the screen after suspend/resume on a Rushmore touchpad. Seen once, cannot reproduce.

6) "Noisy" X/Y values on Rushmore[2]. Reporter is investigating whether this shows up on other drivers. Three possibilities include: i) it's noisy everywhere, even in Windows; ii) the input data is noisy, and the driver needs to clean it up; or iii) the other drivers get "clean" report data but we're using a bad init sequence so our report data is sketchy.

Any hints on reproducing #2, #3, or #5 would be appreciated.

[1] http://www.spinics.net/lists/linux-input/msg25813.html
[2] http://www.spinics.net/lists/linux-input/msg25787.html