Comment 37 for bug 12124

Revision history for this message
Tristian (tr-ce) wrote :

his was a problem for me in Dapper and remains an issue in Edgy.

I have a Alps Glidepoint touchpad on my Toshiba M100, and it is detected as such. Unfortunately, sometimes the mouse jumps around on screen, quadruple taps on movement. Sometimes, moving the mouse results in whatever application I have focused behaving as if I pressed the F7 key (which is really annoying in Firefox- I get ~10 windows asking if I want to enable Caret Browsing).

I opened up /var/log/syslog when using both Dapper (2.6.15) and Edgy (2.6.17) and something approximating the following always shows up when my touchpad goes berserk:

Oct 20 00:35:04 localhost kernel: [17180160.432000] psmouse.c: GlidePoint at isa0060/serio4/input0 lost sync at byte 1
Oct 20 00:35:04 localhost kernel: [17180160.436000] psmouse.c: GlidePoint at isa0060/serio4/input0 - driver resynched.
Oct 20 00:35:04 localhost kernel: [17180160.436000] psmouse.c: GlidePoint at isa0060/serio4/input0 lost sync at byte 1
Oct 20 00:35:04 localhost kernel: [17180160.448000] psmouse.c: GlidePoint at isa0060/serio4/input0 - driver resynched.

In Edgy (2.6.17), a new behavior will sometimes occur:

Oct 20 00:35:05 localhost kernel: [17180161.272000] psmouse.c: GlidePoint at isa0060/serio4/input0 lost synchronization, throwing 1 bytes away.
Oct 20 00:35:06 localhost kernel: [17180161.776000] psmouse.c: resync failed, issuing reconnect request
Oct 20 00:35:06 localhost kernel: [17180162.504000] input: PS/2 Mouse as /class/input/input6
Oct 20 00:35:06 localhost kernel: [17180162.524000] input: AlpsPS/2 ALPS GlidePoint as /class/input/input7

This resyncing results in the Glidepoint being treated only as a PS/2 Mouse (i.e no vertical/horizontal scrolling, no tap-and-drag). Everytime this behavior happens, the two mice are reattached to /class/input/n+1