Bug 1876997 - Touchpad detected but pointer doesn't move on screen
Summary: Touchpad detected but pointer doesn't move on screen
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 32
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1875339 1875828 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-09-08 16:52 UTC by Random User
Modified: 2021-05-25 17:58 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-25 17:58:19 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
libinput record (259.98 KB, text/plain)
2020-09-11 13:08 UTC, Random User
no flags Details
libinput_record kernel 5.7 (45.15 KB, text/plain)
2020-09-11 13:27 UTC, kmlee999
no flags Details
libinput_record kernel 5.8 (87.21 KB, text/plain)
2020-09-11 13:27 UTC, kmlee999
no flags Details
acpidump Asus E200HA (609.49 KB, text/plain)
2020-09-15 06:59 UTC, kmlee999
no flags Details
Asus E200HA acpi-dump (609.64 KB, text/plain)
2020-09-15 16:05 UTC, Random User
no flags Details
Asus e200ha dmi/id kernel 5.8 (1.15 KB, text/plain)
2020-09-16 20:55 UTC, kmlee999
no flags Details

Description Random User 2020-09-08 16:52:51 UTC
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

Comment 1 Fabio Valentini 2020-09-08 21:13:39 UTC
/me reassigns to most probable culprit

Comment 2 kmlee999 2020-09-10 17:21:26 UTC
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.)

Comment 3 Random User 2020-09-10 17:33:38 UTC
@ 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/

Comment 4 Peter Hutterer 2020-09-10 22:16:30 UTC
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

Comment 5 Random User 2020-09-11 13:08:23 UTC
Created attachment 1714558 [details]
libinput record

Comment 6 kmlee999 2020-09-11 13:27:07 UTC
Created attachment 1714561 [details]
libinput_record kernel 5.7

Comment 7 kmlee999 2020-09-11 13:27:52 UTC
Created attachment 1714562 [details]
libinput_record kernel 5.8

Comment 8 Peter Hutterer 2020-09-14 02:31:46 UTC
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?

Comment 9 kmlee999 2020-09-14 08:34:13 UTC
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.

Comment 10 Random User 2020-09-14 16:55:48 UTC
@ 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.

Comment 11 Hans de Goede 2020-09-14 20:23:41 UTC
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.

Comment 12 kmlee999 2020-09-15 06:59:13 UTC
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.

Comment 13 Peter Hutterer 2020-09-15 09:22:46 UTC
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.

Comment 14 Random User 2020-09-15 16:05:33 UTC
Created attachment 1714966 [details]
Asus E200HA acpi-dump

Comment 15 Random User 2020-09-15 16:10:16 UTC
I can confirm that there is a SW_TABLET_MODE in my case, and that the switch is set to 1.

Comment 16 Hans de Goede 2020-09-16 13:16:13 UTC
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

Comment 17 Hans de Goede 2020-09-16 16:26:05 UTC
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

Comment 18 Hans de Goede 2020-09-16 16:29:33 UTC
*** Bug 1875339 has been marked as a duplicate of this bug. ***

Comment 19 Hans de Goede 2020-09-16 16:29:58 UTC
*** Bug 1875828 has been marked as a duplicate of this bug. ***

Comment 20 kmlee999 2020-09-16 20:55:09 UTC
Created attachment 1715129 [details]
Asus e200ha  dmi/id kernel 5.8

Comment 21 kmlee999 2020-09-16 20:56:11 UTC
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.

Comment 22 Felix 2020-09-17 12:24:00 UTC
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"

Comment 23 Random User 2020-09-17 15:59:45 UTC
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 !

Comment 24 Fedora Update System 2020-09-17 20:19:54 UTC
FEDORA-2020-957351614b has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-957351614b

Comment 25 Fedora Update System 2020-09-17 20:20:22 UTC
FEDORA-2020-9f10c3dfae has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-9f10c3dfae

Comment 26 Fedora Update System 2020-09-17 20:20:38 UTC
FEDORA-2020-a3b3084904 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-a3b3084904

Comment 27 Fedora Update System 2020-09-18 16:41:25 UTC
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.

Comment 28 Fedora Update System 2020-09-18 16:42:37 UTC
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.

Comment 29 Fedora Update System 2020-09-18 18:59:19 UTC
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.

Comment 30 Fedora Update System 2020-09-20 23:58:55 UTC
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.

Comment 31 Fedora Update System 2020-09-21 00:01:02 UTC
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.

Comment 32 Martin Vala 2020-09-21 09:13:12 UTC
Working fine for me. Thank you very much

Comment 33 kmlee999 2020-09-21 14:56:14 UTC
Kernel 5.8.10-200.fc32.x86_64 fixes the touchpad issue for me. 
Thanks!

Comment 34 Random User 2020-09-21 18:36:41 UTC
Issue is fixed for me too.
Thanks !

Comment 35 Fedora Update System 2020-09-25 17:01:00 UTC
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.

Comment 36 Fedora Program Management 2021-04-29 17:11:18 UTC
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.

Comment 37 Ben Cotton 2021-05-25 17:58:19 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.