Comment 56 for bug 1506817

Having found a way to reliably reproduce the issue I vaguely understand what is happening.

The kernel psmouse driver probes the TouchPad, reognizes it as a Synaptic touchpad, and performs Synaptic-specific initialization. This happens regardless of whether the TouchPad is switched off in the BIOS or not (!). Then udev recognizes the device and data from the TouchPad will start appearing on /dev/input/event* (in my case, event5). Then X gets started and the xinput infrastructure loads its own input drivers on top of that.

At that point the TouchPad starts to interfere with the physical buttons. When you touch the TouchPad in a particular manner (e.g. with your thumb) before you press a button, then release the button, X does not register a button release event (as per "evtest"), and the button appears stuck. This happens even if the TouchPad is disabled via xinput or using "synclient TouchpadOff=1". It does appear that something somewhere gets confused by the TouchPad button press, even if the TouchPad is supposed to be disabled. (I have tried a variety of synclient/xinput properties, none of them make any difference.)

The issue can be worked around by preventing creation of the device nodes for the TouchPad. Since the BIOS setting to disable the TouchPad does not work reliably (or at all?), that means working around the Synaptics probe in the psmouse kernel module.

So below is another workound, which builds on the workaround in #49. Basically it unloads the kernel psmouse driver, then reloads it with the "bare" mouse protocol. This way the TouchPad is not recognized as a TouchPad any longer, but it also means the TrackPoint is also no longer recognized as a TrackPoint, so the xorg config files need to specify "PS/2 Generic Mouse".

1. Step 4 of #49 needs to be replaced by:

   Section "InputClass"
     Identifier "TrackPoint"
     MatchProduct "PS/2 Generic Mouse"
     MatchDevicePath "/dev/input/event*"
     Option "EmulateWheel" "1"
     Option "EmulateWheelButton" "2"
     Option "Emulate3Buttons" "0"
     Option "XAxisMapping" "6 7"
     Option "YAxisMapping" "4 5"
     Driver "evdev"
   EndSection

2. In /etc/rc.local add:

   modprobe -r psmouse
   modprobe psmouse proto=bare

With this workaround I can no longer reproduce the problem, also after sleep/hibernate cycles. Still it remains a nasty workaround: the TouchPad is dead and system upgrades can easily probably break this workaround at some point, so I hope that the additional information is useful in solving the underlying problem.