Bug 1876997 - Touchpad detected but pointer doesn't move on screen
Summary: Touchpad detected but pointer doesn't move on screen
Keywords:
Status: ON_QA
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: 2020-09-25 17:01 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


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@live.com

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@live.com, 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.


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