Hide Forgot
Description of problem: Since last update, the touchpad does not seem to work anymore. Using evtest, i can see that "something" is happening when i use the touchpad and it's buttons, but the pointer is not moving on screen. Version-Release number of selected component (if applicable): Fedora 32 Bug reproduced using X or Wayland Gnome 3.36.5 Kernel 5.8.6-201 (64 bits) All available updates installed How reproducible: Seems permanent Additional info: OS running on Asus E200HA notebook
/me reassigns to most probable culprit
I have the same issue (touchpad not working since kernel 5.8) on the same laptop (Asus E200HA). Some extra info for debugging: * It works again if I select kernel 5.7.17-200.fc32.x86_64 in grub, but not with either 5.8.4-200.fc32.x86_64 or 5.8.6-201.fc32.x86_64 * It's probably not a kernel module/driver issue: libinput detects "Device: Asus TouchPad, Kernel: /dev/input/event5" in both kernel 5.7 and 5.8. The Xorg.0.log is almost identical between the 2 kernels (only "event11: Asus WMI hotkeys: Keyboard" changed into "event12: Asus WMI hotkeys: Keyboard Switch"). All the lines for "event5 - Asus TouchPad" are identical. * Moreover, "libinput measure touchpad-tap /dev/input/event5" and "libinput measure touchpad-pressure /dev/input/event5" show that touches and taps are detected by libinput in both kernel 5.7 and 5.8. The median and avg measured pressures are about the same (median around 70 for touches). * However, xev does not detect any touchpad events (neither touches nor clicks) with the 5.8 kernels. I'm quite anxious to get this working again: for now I can still work by selecting 5.7 in grub, but that will be gone after any new kernel update (only the 3 most recent kernels are retained by dnf, and I don't know how to change that.)
@ kmlee999 To change the number of old kernels you want to keep, edit /etc/yum.conf or /etc/dnf/dnf.conf and set installonly_limit: installonly_limit=X (X= number of kernel) Source : https://www.if-not-true-then-false.com/2012/delete-remove-old-kernels-on-fedora-centos-red-hat-rhel/
I'll need the output from libinput record for when the device isn't working please, see https://wayland.freedesktop.org/libinput/doc/latest/reporting-bugs.html
Created attachment 1714558 [details] libinput record
Created attachment 1714561 [details] libinput_record kernel 5.7
Created attachment 1714562 [details] libinput_record kernel 5.8
Do you have the touchpad disabled in the gnome settings? Because afaik by replaying the 5.8 kernel log, the touchpad works just fine. libinput debug-events shows the events as expected and the pointer moves as well. So at this point I don't think it's libinput that's at fault here, the issue is somewhere higher up in the stack. does libinput debug-events show expected events for you?
I don't have gnome installed at all: I'm using xorg + lightdm + WindowMaker. It's does not seem to be a problem with WindoeMaker or any window manager: the pointer doesn't move in i3 either, nor in lightdm, nor just starting a bare xterm in startx witnout any window manager. The pointer does appear on screen, it just doesn't react to the touchpad or to clicks. So the issue is somewhere between libinput and xorg. (If it helps, I can attach the Xorg logs from both 5.7 and 5.8). The odd thing is that it's reliably triggered by changing just the kernel. The touchpad/pointer works fine as soon as I reboot with the 5.7 kernel.
@ Peter Hutterer I use Gnome, i have checked if the touchpad is enabled in the settings, it is. I also tried to disable/enable it again, to see if there is something wrong with gnome settings, that didn't change anything. Like kmlee999, that bug came up with the 5.8.x kernel on my notebook. If there is nothing wrong with libinput, then that bug must come from the kernel, as it is very reproductible while changing it. I changed the "component" item from "libinput" to "kernel" in the first report.
Ugh, I'm afraid that this is my fault. I added support for SW_TABLET_MODE to the asus-wmi kernel driver and the patch for that has landed in the 5.8 kernel. Can you please run: sudo dnf install evemu acpica-tools evemu-record And in evemu-record select the "Asus WMI hotkeys" device? I expect that with the 5.8 kernel, you will see that that input device has a SW_TABLET_MODE switch and that that switch reports 1. This causes libinput to think that the device is a 2-in-1 with 360 degree (yoga style) hinges which has been folded into tablet-mode and then it suppresses kbds and touchpad events for the internal kbd and touchpad. If your kbd is still working libinput mis-identifies it as external ... If there indeed is a SW_TABLET_MODE switch being reported and it always reports 1, please run: sudo acpidump -o acpidump-asus-e200ha And than attach the acpidump-asus-e200ha file here? p.s. Peter I have been landing a bunch of patches to report SW_TABLET_MODE on more 2-in-1s, but as this bug shows, code which works on my own test-devices / on actual 2-in-1s might not always work properly on other devices / non 2-in-1s. So if you get more reports which sound like this one, please Cc me.
Created attachment 1714888 [details] acpidump Asus E200HA Indeed there is a SW_TABLET_Mode entry in evemu-record: # Event type 5 (EV_SW) # Event code 1 (SW_TABLET_MODE) # State 1 I attached the acpidump.
Hans: oh, thanks, I didn't know about this. And yes, that would trigger the behaviour. btw for debugging, a simple "libinput debug-events" would also show a TABLET_MODE switch event immediately after starting up (since libinput syncs that switch and generates an event on init). but the evemu above shows that the state is set, that would trigger the libinput behaviour of disabling the touchpad.
Created attachment 1714966 [details] Asus E200HA acpi-dump
I can confirm that there is a SW_TABLET_MODE in my case, and that the switch is set to 1.
Thank you for the acpidump and other info, I'm working on a fix now. Can you also please provide the output of the following command run as a regular user: grep . /sys/class/dmi/id/* 2> /dev/null
I've started a kernel test-build with a patch added which fix this: https://koji.fedoraproject.org/koji/taskinfo?taskID=51598665 ATM this is still building (this takes a couple of hours). Once the build is finished please give this kernel a try. As soon as I've confirmation that the patch indeed fixes things I will submit it for inclusion into the Fedora kernels (as a downstream patch for now). See here for some generic instructions on how to test a kernel directly from koji (our buildsystem): https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt
*** Bug 1875339 has been marked as a duplicate of this bug. ***
*** Bug 1875828 has been marked as a duplicate of this bug. ***
Created attachment 1715129 [details] Asus e200ha dmi/id kernel 5.8
I can confirm that the 5.8.9 test kernel fixes the issue for me. The touchpad works as expected again. Thanks! I attached the dmi/id output.
I confirm that the new kernel work properly now. to take off old kernel do on root #rpm -qa | grep kernel 'here you get the list of all kernel' #dnf remove "the kernel you want remove"
I can't install a test kernel on my machine unfortunatly. Here's the result of "grep . /sys/class/dmi/id/* 2> /dev/null" command /sys/class/dmi/id/bios_date:12/21/2016 /sys/class/dmi/id/bios_release:5.6 /sys/class/dmi/id/bios_vendor:American Megatrends Inc. /sys/class/dmi/id/bios_version:E200HA.303 /sys/class/dmi/id/board_asset_tag:ATN12345678901234567 /sys/class/dmi/id/board_name:E200HA /sys/class/dmi/id/board_vendor:ASUSTeK COMPUTER INC. /sys/class/dmi/id/board_version:1.0 /sys/class/dmi/id/chassis_asset_tag:No Asset Tag /sys/class/dmi/id/chassis_type:10 /sys/class/dmi/id/chassis_vendor:ASUSTeK COMPUTER INC. /sys/class/dmi/id/chassis_version:1.0 /sys/class/dmi/id/modalias:dmi:bvnAmericanMegatrendsInc.:bvrE200HA.303:bd12/21/2016:br5.6:svnASUSTeKCOMPUTERINC.:pnE200HA:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnE200HA:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: /sys/class/dmi/id/product_family:E /sys/class/dmi/id/product_name:E200HA /sys/class/dmi/id/product_sku:ASUS-NotebookSKU /sys/class/dmi/id/product_version:1.0 /sys/class/dmi/id/sys_vendor:ASUSTeK COMPUTER INC. /sys/class/dmi/id/uevent:MODALIAS=dmi:bvnAmericanMegatrendsInc.:bvrE200HA.303:bd12/21/2016:br5.6:svnASUSTeKCOMPUTERINC.:pnE200HA:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnE200HA:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: I will install the patched kernel as soon as it will be available on fedora depot. Thanks for you work !
FEDORA-2020-957351614b has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-957351614b
FEDORA-2020-9f10c3dfae has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-9f10c3dfae
FEDORA-2020-a3b3084904 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-a3b3084904
FEDORA-2020-a3b3084904 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-a3b3084904` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a3b3084904 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-9f10c3dfae has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-9f10c3dfae` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9f10c3dfae See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-957351614b has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-957351614b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-957351614b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-a3b3084904 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-9f10c3dfae has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
Working fine for me. Thank you very much
Kernel 5.8.10-200.fc32.x86_64 fixes the touchpad issue for me. Thanks!
Issue is fixed for me too. Thanks !
FEDORA-2020-957351614b has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-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 '32'. 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 32 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 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 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.