Synaptics touchpad periodically disconnects

Forgot to mention, this is fixed if I kill X or restart GDM. Attached is my X log, the only really relevant part is the last six lines or so.

This seems to happen when I hit caps lock while doing something else, the server will lag, the mouse will disconnect, and then it'll come back without a scroll bar. Attached is my X config.

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Hardy Heron. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at [WWW] http://www.ubuntu.com/testing/.
If it still happens please provide the information described here: https://wiki.ubuntu.com/DebuggingTouchpadDetection.
Thanks again and we appreciate your help.

This still exists in Hardy. I usually trigger it by mashing caps lock while trying to scroll, but there might be other ways.

Hello, I have a similar bug, also with an HP laptop. I will tell you how I can reproduce this:
move the touchpad while pressing caps-lock (the button that toggles the upper case letters) lots of times

this is by bug link https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/243931
I contacted HP for assistance and they told me that I sould use the recovery manager to reinstall windows vista.
Unfortunately in windows vista this problem is better handled by the driver (the touchpad stops wirking for some seconds, but then it works without problems)

Good to know that this isn't just me! I've marked your bug as a duplicate of this one so that anyone who finds one will find the other, and I'm marking yours as confirmed as well.

I really hope that a fix could happen for this -- I don't know much about the driver internals, but it seems like it could be fixed by handling the disconnect (that's caused by the hardware courtesy HP) more gracefully.

Output of xprop -root

Output of gconftool-2 -R /desktop/gnome/peripherals

So, can you reproduce the bug using my steps?

Yes, those are the steps that I've been using to reproduce it. I achieved a fix of sorts by using xmodmap to bind capslock to control, which takes away capslock. However, if I use the Ubuntu keyboard configure app to rebind it, it still disconnects the touchpad.

I can also reproduce the bug just by hitting caps lock while I'm typing fast, when there's no touchpad activity.

Thanks for your tests. I think we'd better contact upstream for a fix.
in the mean time I'd like to figure out if this bug affects all HP
models. I have a DV6627EL.
Let's open a forum thread for this bug

I have a DV9500 and I also suffer from a loss of scrolling on my touchpad after hitting caps lock.

I've vritten to the xorg mailing list and they suggested me two
workaround, neither of which works :(
this is the link of the thread, try it!
http://lists.freedesktop.org/archives/xorg/2008-July/036745.html

Put this file in /etc/hal/fdi/policy/ and reboot. This fixes the reconnect issue.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicolò Chieffo wrote:
> Put this file in /etc/hal/fdi/policy/ and reboot. This fixes the
> reconnect issue.
>
> ** Attachment added: "10-synaptics-hp.fdi"
> http://launchpadlibrarian.net/15789473/10-synaptics-hp.fdi
>
I can confirm that this works! The disconnect still happens and
there's a moment of lag, but the device is successfully identified
upon reconnect.

Maybe this file should be installed with the driver by default?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIhxyJPGdJqB3PmvwRAkFJAJ4zKTCRH+veaCMWwUUy6B1LmmmWEgCbBzz1
3ywVmaj+XOxRUPoOxL/2T8I=
=FrEL
-----END PGP SIGNATURE-----

I'm having a similar problem with an Acer Travelmate 252. After using the touchpad for a while it would stop responding and then start again without the scroll bar working.

On Mon, 2008-08-04 at 23:35 +0000, CirclingTheSun wrote:
> I'm having a similar problem with an Acer Travelmate 252. After using
> the touchpad for a while it would stop responding and then start again
> without the scroll bar working.
>

If you put the file linked above in the directory named above, X will
re-identify the touchpad correctly most of the time. I've experience
some issues, but as I've mapped control over my capslock key, I rarely
reproduce the bug anymore. However, I have tested the file with a
capslock key and it does provide a fix.

The fix seems to be working. I've been running it for about a day now and can still scroll :) Thanks a stack!

Hi tedks,

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with the latest development release of Ubuntu? (ISOs are available from cdimage.ubuntu.com)

If it remains an issue, could you also attach a new /var/log/Xorg.0.log?
Thanks in advance.

Actually the touchpad still disconnects, but I think this is a
hardware problem. For me is fixed, but I really really don't remember
if I put the lines

 <match key="info.capabilities" contains="input.touchpad">
      <match key="info.product" contains="Synaptics TouchPad">
        <merge key="input.x11_driver" type="string">synaptics</merge>

by myself on the file
/usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi or they
were added in xserver-xorg-input-synaptics

Anyway these lines fix the reconnection problem in my case.
Thanks

I'm duplicate this bug https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/293470

The touchpad does still disconnect, but this doesn't seem to be a problem on Intrepid. This bug can probably be marked closed.

The exact same bug is present in Intrepid, also Debian Lenny. Also with vanilla 2.6.28.6. Same behavior with NumLock, the only fix is adding "i8042.dumbkbd=1" to the kernel command lines. I believe this is a hardware issue, the i8042 keyboard/mouse controller chip is broken. This is a "showstopper" bug, however, as Solaris and other operating systems are able to work around it just fine.

[ 381.799121] Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1a0b1, caps: 0xa04713/0x200000
[ 381.910285] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input13
[ 383.147227] Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1a0b1, caps: 0xa04713/0x200000
[ 383.255812] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input14
[ 384.164178] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 4
[ 384.166714] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 384.180164] psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
[ 386.113181] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 4
[ 386.115773] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 386.127721] psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
[ 388.641313] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 388.645209] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 388.647654] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 388.649695] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 388.651669] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 388.651677] psmouse.c: issuing reconnect request
[ 389.945061] Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1a0b1, caps: 0xa04713/0x200000
[ 390.054502] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input15

I have solved the issue to some degree, the caps lock/num lock key seems to cause many bad packets to be generated. adding resetafter=0 (never) to the psmouse options causes things to work normal except the mouse sometimes jumps around. I don't think many updates will really be made to the driver because the AT keyboard and mouse drivers seem so outdated compared to the "HID" drivers.

This also fixes the reconnection problem, because it never disconnects in the first place.