Description of problem: My Lenovo T440s trackpad sometimes stops working, no moves, no clicks no nothing. This also did happen on f21 but way way more often on f22, which is why I'm blaming libinput. I haven't been able to pinpoint the circumstances, they seem to vary. It happened to me last night again. I did a rapid succession of about 10 clicks and the it stopped. Plugging in a BT mouse allows me to use the mouse cursor again, the trackpad seems completely disfunctional. I also tried unbinding and binding it through its /sys file but that didn't work either. The frequency of this problem has reached my tolarance level, it happens too oftern (a few times per week) so I'm filing this bug. Only rebooting the machine makes the trackpad work again. Version-Release number of selected component (if applicable): libinput-0.15.0-4.fc22.x86_64 How reproducible: difficult
anything in dmesg when this happens? or in the journal in general? run evemu-record in a terminal somewhere and when this happens next time check if the touchpad's kernel device is still sending events. if evemu doesn't see events it's a HW or kernel driver issue.
Created attachment 1038386 [details] evemu output As requested. Clearly either a kernel problem (probably) or a hardware problem. I'm betting on kernel problem since it did not occur nearly as often on F21 as it does now.
FYI After resuming the laptop from suspend this morning, the trackpad works again.
If there's no events coming out, then it's a kernel issue, yes. Anything you can pin-point as to the cause of it? It's most likely a multi-finger gesture that triggers it, tapping or scrolling.
Can't say that it's clear what triggers it. The last time it happened I was merely moving the mouse right after a click (IIRC).
Apologies for the late answer. In case you are still experiencing the problem, can you attach a dmesg right after the problem appears? I am not very confident in our ability to fix this. A lot of people have a t440s, and this is the first time I hear that the touchpad blocks while in the ps/2 mode. Next time it happens, you can also try to run (as root): #> echo -n rescan > /sys/devices/platform/i8042/serio1/drvctl This will trigger a rescan of the PS/2 controller and should hopefully have the same effect than a suspend/resume.
Will try that when it happens again. It hasn't happened for a while now (and me saying that probably trigger it very soon).
And about one hour after the previous reply it hit. I had to change > #> echo -n rescan > /sys/devices/platform/i8042/serio1/drvctl to #> echo -n rescan > /sys/devices/platform/i8042/serio0/drvctl Will attach dmesg
Created attachment 1058674 [details] dmesg dmesg right after the touchpad stopped working
(In reply to Ferry Huberts from comment #8) > And about one hour after the previous reply it hit. > > I had to change > > #> echo -n rescan > /sys/devices/platform/i8042/serio1/drvctl > > to > #> echo -n rescan > /sys/devices/platform/i8042/serio0/drvctl Hmm. This is weird, the serio0 controller is the one for the keyboard, while the serio1 is attached to the touchpad/trackstick. I would expect that you need to resync only the touchpad. > > Will attach dmesg Thanks for the dmesg. So according to it, your t440s is one of the refreshed ones with a correctly reported min/max. This might be why we haven't seen this problem that often (we mostly worked with the first iteration of the device). It looks like you get a lot of "lost sync bytes" (every 1000 secs when this happens a lot I would say), and I wonder if we should not switch your device in the RMI4 over SMBus mode. I will build a special kernel for you to test this implementation. We are still waiting for upstream to include it, so if this work, you might need to stay with special kernels until it gets included.
> I will build a special kernel for you to test this implementation. We are > still waiting for upstream to include it, so if this work, you might need to > stay with special kernels until it gets included. I can easily test that kernel but the problem doesn't happen that often, sometimes it takes weeks. However, I'll just stay with regular kernels since I now have a tiny script to rescan.
(In reply to Benjamin Tissoires from comment #10) > (In reply to Ferry Huberts from comment #8) > > And about one hour after the previous reply it hit. > > > > I had to change > > > #> echo -n rescan > /sys/devices/platform/i8042/serio1/drvctl > > > > to > > #> echo -n rescan > /sys/devices/platform/i8042/serio0/drvctl > > Hmm. This is weird, the serio0 controller is the one for the keyboard, while > the serio1 is attached to the touchpad/trackstick. I would expect that you > need to resync only the touchpad. > It just happened again and I found out that serio0 has no effect, it really must be serio1 like you said. It just takes a while after the rescan command for the mouse to move again. Must have been faster than that last time.
(In reply to Ferry Huberts from comment #11) > I can easily test that kernel but the problem doesn't happen that often, > sometimes it takes weeks. > > However, I'll just stay with regular kernels since I now have a tiny script > to rescan. Can I ask you to test however http://koji.fedoraproject.org/koji/taskinfo?taskID=10615299 ? This build contains the last version of Synaptics RMI4 over SMBus and should be stable enough for testings. If you do not get any more locks of the pointer, then that will be an other argument in our hands to push this.
Actually, we just spotted a suspend/resume problem with the scratch-build I gave you. Can you try this one instead? http://koji.fedoraproject.org/koji/taskinfo?taskID=10624277
Can you redo a build that I can test? Sorry I didn't get to the one you created earlier. And right now it is quite bad. xorg-x11-server-common 1.17.2-2.fc22.2.x86_64 libinput 1.0.1-2.fc22.x86_64 kernel 4.1.10-200.fc22.x86_64
OK, I'll try to make a new build today. No guarantees though because I was swamped today and Lyude reported (and fixed) some issues with suspend/resume that I need to review first before making a new build. Hopefully tonight or tomorrow the build should be ready.
I just launched http://koji.fedoraproject.org/koji/taskinfo?taskID=11505782 No guarantees the build will end. I have only tested the patch series on top of a 4.3-rc6, so I hope it will work on this fedora based kernel.
I've had this kernel installed for a few hours now. I didn't /really/ work with it yet, just browsing and email but I can already 'feel' the difference. The pad feels much better, way more responsive. Can't really put my finger on it though. There /is/ one thing I did notice: In the original kernel the pad had a pause right between clicking and being able to move the pointer again. In this kernel I didn't notice that (yet). Will report back in a few days after I've worked a bit more with it.
(In reply to Ferry Huberts from comment #18) > There /is/ one thing I did notice: > In the original kernel the pad had a pause right between clicking and being > able to move the pointer again. In this kernel I didn't notice that (yet). Hmm, this must be libinput related. Peter, any comments? > > Will report back in a few days after I've worked a bit more with it. Thanks. Please do so. Taking this work upstream takes longer than expected, but we will do it, I promise!
shouldn't be a timeout, but we have a distance threshold on the finger that pressed the physical button (1.5mm). if you more more than that, motion events are accepted again. if the kernel changed things like resolution/finger capabilities or so then this may look like a timeout that went away.
The trackpad doesn't come back up after a suspend/resume cycle, and doing a rescan also doesn't make it come back.
For the first time in ages I see think appear in the syslog. And the messeages coincide with the observed stuttering I do hope you can fix this, it is utterly annoying. More so now that my BT mouse has stopped working somehow after an update Dec 16 21:03:30 stinkpad.internal.hupie.com kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Dec 16 21:03:30 stinkpad.internal.hupie.com kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 - driver resynced. Dec 16 21:04:23 stinkpad.internal.hupie.com kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4 Dec 16 21:04:23 stinkpad.internal.hupie.com kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Dec 16 21:04:23 stinkpad.internal.hupie.com kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Dec 16 21:04:23 stinkpad.internal.hupie.com kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Dec 16 21:04:23 stinkpad.internal.hupie.com kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4 Dec 16 21:04:23 stinkpad.internal.hupie.com kernel: psmouse serio1: issuing reconnect request Dec 16 21:04:24 stinkpad.internal.hupie.com kernel: psmouse serio1: synaptics: queried max coordinates: x [..5112], y [..3834] Dec 16 21:04:24 stinkpad.internal.hupie.com kernel: psmouse serio1: synaptics: queried min coordinates: x [1024..], y [1024..] Dec 16 21:04:24 stinkpad.internal.hupie.com kernel: psmouse serio1: synaptics: quirked min/max coordinates: x [1024..5112], y [2024..4832] Dec 16 21:04:32 stinkpad.internal.hupie.com kernel: psmouse serio1: bad data from KBC - timeout Dec 16 21:04:39 stinkpad.internal.hupie.com kernel: psmouse serio1: bad data from KBC - timeout Dec 16 21:05:04 stinkpad.internal.hupie.com kernel: psmouse serio1: bad data from KBC - timeout Dec 16 21:05:04 stinkpad.internal.hupie.com kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Dec 16 21:05:04 stinkpad.internal.hupie.com kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Dec 16 21:05:04 stinkpad.internal.hupie.com kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Dec 16 21:05:04 stinkpad.internal.hupie.com kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Dec 16 21:05:04 stinkpad.internal.hupie.com kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Dec 16 21:05:04 stinkpad.internal.hupie.com kernel: psmouse serio1: issuing reconnect request Dec 16 21:05:04 stinkpad.internal.hupie.com kernel: psmouse serio1: synaptics: queried max coordinates: x [..5112], y [..3834] Dec 16 21:05:04 stinkpad.internal.hupie.com kernel: psmouse serio1: synaptics: queried min coordinates: x [1024..], y [1024..] Dec 16 21:05:04 stinkpad.internal.hupie.com kernel: psmouse serio1: synaptics: quirked min/max coordinates: x [1024..5112], y [2024..4832] Dec 16 21:05:35 stinkpad.internal.hupie.com kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4 Dec 16 21:05:35 stinkpad.internal.hupie.com kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Dec 16 21:05:35 stinkpad.internal.hupie.com kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Dec 16 21:05:35 stinkpad.internal.hupie.com kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Dec 16 21:05:35 stinkpad.internal.hupie.com kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Dec 16 21:05:35 stinkpad.internal.hupie.com kernel: psmouse serio1: issuing reconnect request Dec 16 21:05:35 stinkpad.internal.hupie.com kernel: psmouse serio1: synaptics: queried max coordinates: x [..5112], y [..3834] Dec 16 21:05:35 stinkpad.internal.hupie.com kernel: psmouse serio1: synaptics: queried min coordinates: x [1024..], y [1024..] Dec 16 21:05:35 stinkpad.internal.hupie.com kernel: psmouse serio1: synaptics: quirked min/max coordinates: x [1024..5112], y [2024..4832]
kernel 4.2.7-300.fc23.x86_64
urgh, sorry about dropping this one. Is still an issue? looks like we're at 4.4.6 now in F23.
Yes, still an issue Not as bad as before but it does happen. It seems to be the case that once it happens the first time after a fresh cold-start of the machine that it starts happening a lot more (like before). I bring the trackpad back by doing a rescan. That works most of the time (like 99%)
Hi, i think the same problem happens to me after nearest upgrade of fedora. My situation is: hardware: Lenovo G470 OS: Linux 4.4.7-300.fc23.x86_64 system works fine until locking screen, when i try to wake up by moving mouse or press some key, the screen not response and disk io light keep flashing. After a long while, the login screen comes back but system becomes very slow. this problem must to cold reboot to resolve, and this situation can be reproduced. after this problem happened, i found below message in Xorg.0.log: [ 853.258] (II) SYN_DROPPED event from "PixArt USB Optical Mouse" - some input events have been lost.
after upgrading to Linux 4.4.7-300, the problem is still on. But, it is resolved now ! My laptop has switchable graphics, there is a configuration item for that. i changed the value from "switchable graphics" to "UMA graphic", and now the issue is gone. hope helpful
Well, my t440s doesn't have that and for me the issue is still there. Quite heavily.
Well, my t440s doesn't have that and for me the issue is still there. Quite heavily. It does seem to be related to physical action: pressing down the trackpad seems to trigger the problem. tap-to-click never triggered the problem for me. However, this could also be 'wrong' handling of what happen when pressing down the pad: I never take my fingers from the pad when pressing it down to click. Maybe there is a problem in that handling path.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs. Fedora 23 has now been rebased to 4.7.4-100.fc23. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs. Fedora 25 has now been rebased to 4.10.9-100.fc24. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26. If you experience different issues, please open a new bug report for those.
still the case on F25
This issue has become progressively worse over the last couple of kernels. It's now so bad that it's hardly workable, the pad stops responding like every 5 minutes or so. I'm on Fedora 25 x64 with kernel Linux stinkpad 4.10.10-200.fc25.x86_64 #1 SMP Thu Apr 13 01:11:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux a short log exerpt: Apr 21 09:43:23 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:43:23 stinkpad kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4 Apr 21 09:43:23 stinkpad kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 21 09:43:23 stinkpad kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 21 09:43:23 stinkpad kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 21 09:43:23 stinkpad kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 21 09:43:23 stinkpad kernel: psmouse serio1: issuing reconnect request Apr 21 09:43:23 stinkpad kernel: psmouse serio1: synaptics: queried max coordinates: x [..5112], y [..3834] Apr 21 09:43:23 stinkpad kernel: psmouse serio1: synaptics: queried min coordinates: x [1024..], y [1024..] Apr 21 09:43:23 stinkpad kernel: psmouse serio1: synaptics: quirked min/max coordinates: x [1024..5112], y [2024..4832] Apr 21 09:43:25 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:43:25 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:43:25 stinkpad kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 21 09:43:25 stinkpad kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 - driver resynced. Apr 21 09:43:27 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:43:27 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:43:27 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:43:27 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:43:27 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:43:27 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:43:27 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:43:27 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:43:27 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:43:27 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:43:27 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:43:27 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:44:01 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:44:01 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:44:01 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:44:01 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:44:01 stinkpad kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4 Apr 21 09:44:01 stinkpad kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 21 09:44:01 stinkpad kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 21 09:44:01 stinkpad kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 21 09:44:01 stinkpad kernel: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 21 09:44:01 stinkpad kernel: psmouse serio1: issuing reconnect request Apr 21 09:44:02 stinkpad kernel: psmouse serio1: synaptics: queried max coordinates: x [..5112], y [..3834] Apr 21 09:44:02 stinkpad kernel: psmouse serio1: synaptics: queried min coordinates: x [1024..], y [1024..] Apr 21 09:44:02 stinkpad kernel: psmouse serio1: synaptics: quirked min/max coordinates: x [1024..5112], y [2024..4832] Apr 21 09:44:09 stinkpad kernel: psmouse serio1: bad data from KBC - timeout Apr 21 09:44:09 stinkpad kernel: psmouse serio1: bad data from KBC - timeout
Also, the 'lost sync' things are very very noticable: moving the mouse and then a 'lost sync' occurs presents itself as the pointer stopping and only resuming after the sync is aquired again. kind of unworkable
Well, I tried pushing the now upstream patches in Fedora, without any luck. However, these patches that support the touchpad with RMI4 over SMBus will be in v4.12-rc0 that should be out in a couple of weeks. Please report once this kernel hits rawhide.
I'm on F25 and it's my work machine. I can briefly try the rawhide kernel but obviously I'm not tracking rawhide. Ping me when that kernel is available please.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.