Created attachment 210911 [details] full dmesg output. Please note the actual event seems to coincide with "Failed to enable mouse on ..." at the bottom First of all sorry for escalating this to here again, it appears Fedora maintainers are currently struggling a bit with catching up with the kernel bug reports... original bug ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1313939 The trackpoint and touchpad randomly stop working after 30 minutes or longer of working fine. This happens quite reliably at some point, although the duration until it happens is random. A reboot always fixes it, but it's still annoying to be required to reboot every 30 minutes to 5 hours. When it happens, it seems to coincide with the following line in dmesg: "[ 3265.497495] psmouse serio1: Failed to enable mouse on isa0060/serio1" Full dmesg output is attached, where you will be able to see that psmouse is already quite unhappy for a while before (but the touchpad/trackpoint work fine during that period), until eventually it seems to break entirely. Version-Release number of selected component (if applicable): Linux localhost.localdomain 4.4.2-301.fc23.x86_64 #1 SMP Tue Feb 23 19:00:38 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux How reproducible: 99% (waiting period differs but it takes less than 5 hours of usage to reproduce with a very high probability) Steps to Reproduce: 1. Use laptop's touchpad, trackpoint and occassionally the pen and touchscreen 2. Do this for a while (e.g. browsing documents is a good use case) 3. Eventually, touchpad/trackpoint suddenly stop working Actual results: Touchpad/trackpoint stop working. A reboot fixes it temporarily Expected results: Touchpad/trackpoint keep working
In case this is relevant, this kernel is running with the option irqpoll nolapic to workaround bug https://bugzilla.kernel.org/show_bug.cgi?id=110941
For completeness I'll re-post what I wrote for the Fedora bug report with some additions: I am having a similar problem with my Thinkpad Yoga 12 on Fedora 23. uname -r outputs: 4.4.6-300.fc23.x86_64 I am using no special kernel options other than i8042.debug=1 Description: After using my computer normally for a while, my trackpoint and touchpad stop responding. So I am not able to move my mouse with them. My touch screen and digitizer pen still work. Sometimes, after waiting about 10mins, they start to work again. Other times, they stop functioning entirely and no longer show up in xinput. While the trackpoint and touchpad are not working, my keyboard also periodically lags, and the same keystroke is repeated many times. Keyboard freezes coincide with the following kernel messages: [ 1859.197026] psmouse serio1: synaptics: queried min coordinates: x [1232..], y [1074..] Tilting the computer also causes the touchpad/trackpoint to freeze temporarily. Messages like the one related to the keyboard lag appear. Could it be that the STMicro Sensor Hub in the laptop is related to this issue? i8042's debug output shows events when I use my touchpad, trackpoint, or keyboard. But it also shows events when I tilt my computer. I've tried disabling the Sensor Hub in the BIOS but I still get i8042 interrupts from the device with it disabled. If that's even possible... I have attached a snippet of my dmesg output starting at the point when my trackpoint and touchpad stop working, and ending when they start working again. Additional Info: I have tried live booting other distributions and other kernel versions. This includes Ubuntu 15.10, Ubuntu 15.04, and the latest version of Elementary OS. I get the same problem and same kernel messages in all of these environments. This leads me to think it's a kernel issue? Although all of these distros have different kernel versions... I have also tried reloading psmouse with the proto=bare option. This did not help. AskUbuntu Thread discussing the same issue: http://askubuntu.com/questions/749280/trackpad-and-keyboard-erratic-behaviour-on-thinkpad-yoga-15-10/749890#749890
Created attachment 211111 [details] dmesg output starting when the trackpoint/touchpad stop working, and ending when they start working again
Another variant of the reconnect failure after which the touchpad and trackpoint both dropped dead: [644807.784754] psmouse serio1: issuing reconnect request [644829.638680] psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6 [644829.645747] psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6 [644829.652764] psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6 [644829.659910] psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6 [644829.669208] psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6 [644829.669211] psmouse serio1: issuing reconnect request [644829.830100] psmouse serio1: elantech: synaptics_send_cmd query 0x01 failed. [644830.607725] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x4d1f04) [644830.618571] psmouse serio1: elantech: Synaptics capabilities query result 0x80, 0x14, 0x0c. [644830.629857] psmouse serio1: elantech: Elan sample query result 04, 01, 85 [644831.162956] psmouse serio1: elantech: elantech_send_cmd query 0x00 failed. [644831.162960] psmouse serio1: elantech: failed to query touchpad range. [644831.451426] input: PS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input33
So I think when you click(button) and drag(trackpoint) while touching the touchpad, the device sends a packet of type `0x03` which is not getting handled here: https://github.com/torvalds/linux/blob/9256d5a308c95a50c6e85d682492ae1f86a70f9b/drivers/input/mouse/elantech.c#L813-L822 This is what it looks like when this happens: https://www.youtube.com/watch?v=QH-tYESsgSI When enabling the psmouse debug mode, the fourth byte of the packet immediately before it fails always has packet type `0x03`. (I came here from that same Fedora thread)
You can also reproduce the behavior by clicking one physical button and the clickpad at the same time while moving your finger on the touchpad, so this might be a problem with not being able to accept three different packets which were sent very quickly.
Can reproduce problem here. After a certain amount of usage touchpad becomes unresponsive. While the touchpad is unresponsive, no keyboard input comes through either. Unloading and the reloading the psmouse driver fixes the issue temporarily, and allows the (i assume queued) keybord input through. I'll gladly help debugging the issue, as it's keeping me from using Linux on this laptop.
@Jonathan I got same issue like described in your video but with the trackpoint + synaptic touchpad on thinkpad laptop generation 2015 (or above) which has a clickpad design. I could reproduce the issue with this way: With the touchpad being disabled, put your two fingers on the touchpad, then click the trackpoint's left button on the desktop, and then move the pointing stick afterwards, if the issue happends, it would produce "hold left button and dragging movement". So it's just like a click lock (holding button) effect on the trackpoint's left button. I wonder if you ever find a workaround for this issue?
I've gotten to the point of mitigating the issue by reloading the psmouse module every 30 seconds. That way I have to wait max 30 secs instead of rebooting/sleeping. A rudimentary look at my own issue shows that the psmouse driver "gets stuck" due to certain errors in the input from the hardware device. Instead of resyncing it simply locks up.