Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Have a laptop with an AlpsPS/2 ALPS DualPoint TouchPad 2. Continuously use said laptop. 3. Eventually the cursor begins to freeze up (stops responding to touchpad) Actual results: Cursor stops responding to touchpad movement. Expected results: Cursor should keep on responding to touchpad movement. Additional info: I have a Lenovo Thinkpad Edge E455 laptop with an ALPS DualPoint TouchPad and track stick. In Fedora 22 and other distributions used, the touchpad events cease to be processed after some random amount of time being used. The trackstick can still control the cursor. From the windows alps input driver given by lenovo, it seems that this touchpad uses version 8 of the alps protocol. I've used evemu-record to track the input events when the cursor stops responding to the touchpad and have found out that it doesn't register any movement by the touchpad. Upon watching interrupts during that period, the touchpad interrupts are still being registered. There are no error-significant messages pertaining to the touchpad in either dmesg or Xorg.0.log during that period. Using Fedora, only rebooting the system brings back touchpad functionality. On other distributions in which psmouse is compiled in the kernel as a module, a simple reload of the psmouse module brings back functionality until it locks up back again requiring another reload. Anyone has an idea about this? I'm thinking this might be a protocol issue.
Hello! So, since evdev isn't reporting any motion events when the touchpad stops working this is most definitely an issue with the kernel driver. What this means is that the most useful thing we can get to debug this issue would be a ps2emu recording of your TouchPad so that we can replay the Touchpad on our machines and reproduce the bug here. We currently have ps2emu-tools available in the Fedora copr at https://copr.fedoraproject.org/coprs/lyude/ps2emu-tools/ . You can enable the copr and install the package with the following commands: sudo dnf -y copr enable lyude/ps2emu-tools sudo dnf -y install ps2emu-tools Once you've done that, recording is pretty simple. Just run sudo ps2emu-record > foo.txt And the tool will rescan and record all of the PS/2 data coming from and going to the touchpad. This being said, since the tool initiates a rescan of all the PS/2 ports on the system, this will reset your touchpad. So you'll unfortunately have to keep the tool running until the bug appears. Once you've gotten the bug recorded, you can end the recording with ^C (Ctrl + C). In addition, it should be noted that this tool enables i8042 debugging, which means that all PS/2 devices (your laptop's keyboard included) will have their data dumped to dmesg, although ps2emu-record will not record any PS/2 data that doesn't come from your touchpad by default. This being said however, this means anything you type with the inclusion of your password will be dumped to your dmesg. We have a kernel patch waiting to get merged that fixes this issue. I'll also give you a temporary workaround you can use for when your touchpad starts acting up. Although psmouse is built into the kernel by default, you can trigger a reset of the touchpad with: sudo bash -c 'echo -n rescan > /sys/devices/platform/i8042/serio1/drvctl' On some devices the PS/2 is multiplexed, which means there will be more then 2 serio directories in /sys/devices/platform/i8042, and serio1 might not be the one that corresponds with your touchpad. If that's the case, try each one until you see the touchpad reconnect in dmesg.
I think I've figured out what's going wrong. It's an issue in the kernel pertaining to multigestures (ie two finger scrolling in my case). Using the default libinput configuration, the "scrollmethod" option is set to both twofinger and edge. Upon using the default selection, the bug occurs. Changing the scrolling method to only two finger in X11.conf.d also produces the same while using edge only results in the bug never occurring. I'll post the dump soon since I know what causes the issue now.
*********** 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 22 kernel bugs. Fedora 22 has now been rebased to 4.2.3-200.fc22. 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 23, and are still experiencing this issue, please change the version to Fedora 23. If you experience different issues, please open a new bug report for those.
Since recent kernel upgrades, the problem doesn't show up spontaneously anymore. Might as well close this.