This is my first bug report to kernel.org, and I'd appreciate any feedback if I'm doing anything wrong. I've written a bit on this issue on AskUbuntu, but haven't had any response there yet, so I'm opening a ticket here. Please advise if this issue would be better reported to freedesktop. https://askubuntu.com/questions/991151/ubuntu-17-10-elantech-touchpad-jerky-and-sluggish-with-phantom-click-events I have an ASUS GL503VD running a fresh Ubuntu 17.10. The Elantech touchpad is picked up by the system, but (1) it behaves very sluggishly with noticeable lag and delay, so that the pointer jumps around on the screen, making it very hard to use (e.g., it's difficult to get the cursor onto small minimize or close buttons in the desktop). (2) With tapping enabled, the touchpad generates a log of click events, so life is much better with tapping turned off. The behaviour described in this AskUbuntu question sounds similar to what I'm observing: https://askubuntu.com/questions/981183/asus-fx503vd-elan1200-touchpad-not-working-smoothly Sometimes the touchpad stops responding completely for half a minute or so; I haven't found a way to reliably reproduce this. This problem can be fixed by suspending the machine and then waking it up again. (3) Running under Wayland or X11, top shows a process called `irq/131-ELAN120` with priority -51 that consistently uses about 10% of the CPU. Further, powertop shows an interrupt called `idma64.0` which is also triggered hundreds of times per second. If I disable the touchpad (e.g., in BIOS), the laptop battery life is improved by about an hour. At the moment, the touchpad is so hard to use that I mostly plug in an external mouse; whatever the driver stack is doing mostly just serves to drain the battery. I'm hoping to discover kernel options or module parameters to help resolve these three symptoms in case this is just a configuration problem with my particular setup; failing that, perhaps somebody can help to narrow down where my problem is coming from, in the hope that this helps other folks with the same hardware as me. I've experimented with most of the parameters to i8042, without any effect on the touchpad behaviour. I've also played around with acpi_osi, pci=noacpi, pnpacpi=off, and noapic options without any improvement. The machine's BIOS is up to date, and I've built what I hope is a vanilla kernel version 4.15.0-rc7 following the steps at https://wiki.ubuntu.com/KernelTeam/GitKernelBuild. I've also updated libinput to version 1.9.0, which also didn't make any difference. Note: I haven't found a configuration where the touchpad wasn't sick. I've tried Live disks for Ubuntu 17.10, 17.04, 16.04, and Mint 18.3 MATE, all of which behave the same. $ scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux aleppo 4.15.0-rc7-custom #1 SMP Sun Jan 14 12:23:38 CET 2018 x86_64 x86_64 x86_64 GNU/Linux GNU Make 4.1 Binutils 2.29.1 Util-linux 2.30.1 Mount 2.30.1 Module-init-tools 24 E2fsprogs 1.43.5 Pcmciautils 018 PPP 2.4.7 Linux C Library 2.26 Dynamic linker (ldd) 2.26 Linux C++ Library 6.0.24 Procps 3.3.12 Net-tools 2.10 Kbd 2.0.3 Console-tools 2.0.3 Sh-utils 8.26 Udev 234 Wireless-tools 30 Modules Loaded acpi_pad aesni_intel aes_x86_64 ahci arc4 asus_nb_wmi asus_wireless asus_wmi autofs4 bbswitch binfmt_misc bluetooth bnep btbcm btintel btrtl btusb ccm cfg80211 cmac coretemp crc32_pclmul crct10dif_pclmul cryptd crypto_simd drm drm_kms_helper ecdh_generic fb_sys_fops ghash_clmulni_intel glue_helper hid hid_generic hid_multitouch i2c_algo_bit i2c_hid i915 idma64 input_leds intel_cstate intel_lpss intel_lpss_pci intel_pch_thermal intel_powerclamp intel_rapl intel_rapl_perf ip_tables irqbypass iwlmvm iwlwifi joydev kvm kvm_intel libahci lp mac80211 mac_hid media mei mei_me memstick mii msr mxm_wmi nls_iso8859_1 parport parport_pc pcbc pinctrl_intel pinctrl_sunrisepoint ppdev psmouse r8169 rfcomm rtsx_pci rtsx_pci_ms rtsx_pci_sdmmc serio_raw shpchp snd snd_hda_codec snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_core snd_hda_intel snd_hwdep snd_pcm snd_rawmidi snd_seq snd_seq_device snd_seq_midi snd_seq_midi_event snd_timer soundcore sparse_keymap syscopyarea sysfillrect sysimgblt tpm_crb usbhid uvcvideo video videobuf2_core videobuf2_memops videobuf2_v4l2 videobuf2_vmalloc videodev virt_dma wmi x86_pkg_temp_thermal x_tables $ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ ITE Tech. Inc. ITE Device(8910) id=13 [slave pointer (2)] ⎜ ↳ ELAN1200:00 04F3:3090 Touchpad id=14 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Asus Wireless Radio Control id=7 [slave keyboard (3)] ↳ Video Bus id=8 [slave keyboard (3)] ↳ Video Bus id=9 [slave keyboard (3)] ↳ Power Button id=10 [slave keyboard (3)] ↳ Sleep Button id=11 [slave keyboard (3)] ↳ USB2.0 HD UVC WebCam: USB2.0 HD id=12 [slave keyboard (3)] ↳ Asus WMI hotkeys id=15 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=16 [slave keyboard (3)] ↳ ITE Tech. Inc. ITE Device(8910) id=17 [slave keyboard (3)] $ xinput list-props 14 Device 'ELAN1200:00 04F3:3090 Touchpad': Device Enabled (142): 1 Coordinate Transformation Matrix (144): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Tapping Enabled (285): 0 libinput Tapping Enabled Default (286): 0 libinput Tapping Drag Enabled (287): 1 libinput Tapping Drag Enabled Default (288): 1 libinput Tapping Drag Lock Enabled (289): 0 libinput Tapping Drag Lock Enabled Default (290): 0 libinput Tapping Button Mapping Enabled (291): 1, 0 libinput Tapping Button Mapping Default (292): 1, 0 libinput Accel Speed (293): 0.000000 libinput Accel Speed Default (294): 0.000000 libinput Natural Scrolling Enabled (277): 0 libinput Natural Scrolling Enabled Default (278): 0 libinput Send Events Modes Available (262): 1, 1 libinput Send Events Mode Enabled (263): 0, 0 libinput Send Events Mode Enabled Default (264): 0, 0 libinput Left Handed Enabled (279): 0 libinput Left Handed Enabled Default (280): 0 libinput Scroll Methods Available (295): 1, 1, 0 libinput Scroll Method Enabled (296): 1, 0, 0 libinput Scroll Method Enabled Default (297): 1, 0, 0 libinput Click Methods Available (298): 1, 1 libinput Click Method Enabled (299): 1, 0 libinput Click Method Enabled Default (300): 1, 0 libinput Middle Emulation Enabled (281): 0 libinput Middle Emulation Enabled Default (282): 0 libinput Disable While Typing Enabled (301): 1 libinput Disable While Typing Enabled Default (302): 1 Device Node (265): "/dev/input/event10" Device Product ID (266): 1267, 12432 libinput Drag Lock Buttons (283): <no items> libinput Horizontal Scroll Enabled (284): 1
Created attachment 273599 [details] dmesg
Created attachment 273601 [details] lspci -vvv
Created attachment 273603 [details] lsmod
Created attachment 273605 [details] cat /proc/interrupts
Created attachment 273607 [details] dmesg with i8042.debug=1
Update: when the touchpad freezes, libinput-debug-events doesn't show anything coming from the touchpad. Suspend/resume fixes this. Dmesg doesn't show anything ... should I be checking somewhere else for logs?
Created attachment 273625 [details] acpidump
Created attachment 273627 [details] fwts results.log
Created attachment 273677 [details] evemu-record /dev/input/event9 This recording captures the touchpad, and includes one instance of the touchpad dropping out near the end. This is the 63.7 second gap in the event stream between 980 and 1044: I was moving my finger, tapping, dragging, etc. the whole time during this period, but no events come in. Note how touchpad events are often 20-70 ms between updates.
Created attachment 273679 [details] evemu-record /dev/input/event17 For comparison, this is a recording of using a cheapo external Logitech USB laser mouse, which works fine on my system. In contrast to the touchpad, events here usually come 10 ms or less apart.
Created attachment 273681 [details] evtest /dev/input/event9
Update: I can reliably produce the touchpad freeze by doing a five finger tap on the touchpad.
Created attachment 273729 [details] lshw
Created attachment 273733 [details] hid-recorder /dev/hidraw2 http://bentiss.github.io/hid-replay-docs/ This is a hidraw recording of the touchpad. Near the end of the recording I did a 5-finger tap and the touchpad stopped responding; I'm not sure how to see this in the hidraw recording---the end of the file ends with all zeroes, but perhaps I had already lifted my fingers off the touchpad by that point. When I play this back, the motion looks smooth and not jumpy. The mouse buttons seem to be working alright, and the scrolling looks smooth. If I play the file back twice, the pointer does the same motion twice. I wonder if this means that whatever causes the touchpad to become unresponsive, it's happening in the code which interprets the hid stream...
Created attachment 273735 [details] hid-recorder /dev/hidraw0 For comparison, this is a hidraw recording of the USB mouse.
Here's a little Python analysis of the intervals between events, comparing recording at evemu and hid-recorder: https://github.com/wroberts/asus-notebook/blob/master/analyse-times.ipynb The plots in there are showing histograms of how many seconds fall between subsequent events. For me, the difference between the USB mouse and the touchpad are quite visible on the evemu recordings at the bottom of the notebook. The touchpad sends a lot of events closely together, but it has a tail, where events are often 50 or 70 ms apart, and sometimes they're even over 100 ms apart. The USB mouse doesn't show this behaviour. On the hid-recorder, the pattern, if anything, is in the opposite (although bear in mind that the scale on the x-axis is smaller). The touchpad events all seem to come very close together, and the USB mouse seems to have a bit more variance in the event stream rate. The USB mouse behaviour, though, both while doing the hid-recorder, and later during playback, was perfectly acceptable to me. Thus, I guess the odd 40 or 60 ms delay between events is OK when using the USB mouse. OK, so I'm thinking that this shows that the lagginess (and other general flakiness like phantom button presses when tap-to-click is turned on) that I'm seeing in the touchpad is introduced in the kernel, somewhere between where the HID events originate (is this i2c_hid?) and where they get turned into input events (i2c_designware? hid-multitouch? I'm not sure.).
Update: I can also recover from a frozen touchpad with: rmmod hid-multitouch ; modprobe hid-multitouch
Created attachment 273785 [details] dmesg with i2c_hid.debug=1
I can confirm that I am having the same issue running linux mint 18.3 on an ASUS GL503VM (s5am Faker). I found slightly better results if i set the priority of the irq/131-ELAN120 process to very high, however it is still barely usable. Did you happen to find anything to help this issue in the 2 months since you reported?
Hi Jake, Thanks for your message. I'll have to try out setting the priority of the ELAN1200 process, that sounds interesting. I haven't had any time to work on this issue since reporting the bug. The flakiness (touchpad works, but not well) and reproducible crashing behaviour (on five-finger taps) make me suspect that there's some problem happening in the kernel's driver stack somewhere (at the moment, I'm most suspicious of hid-multitouch), but I'm lacking both the skill and free time to track down the exact cause or propose a fix. It would be great to get somebody expert like Benjamin Tissoires to take a quick look at this in case anything pops out or we can collect any other output that would help with diagnosis, but I'm not sure how to go about that. I've written to the linux-input mailing list once, but that didn't seem to do anything. Hopefully I'll be able to get back to fighting this issue in a few months. Best, Will
Hello Will Roberts. Benjamin Tissoires is already investigating a similar bug here : https://bugzilla.redhat.com/show_bug.cgi?id=1543769 The touchpad ID is 04F3:303E The bug is not solved yet but we have excluded any hardware failures for that case.
Hi PapsOu, thanks very much for the link! That bug sounds very similar, and it looks like there's progress being made. Fingers crossed that we'll figure out this problem soon.
Hi Will, Hi Jake, I don't know if you follow my bug report on redhat bugzilla, but there's a good progress ! The problem has been identified : the GPIO mapping has « holes ». So the IRQs were not correctly assigned. If you build your own kernel with patches found here (https://bugzilla.redhat.com/show_bug.cgi?id=1543769#c87) your touchpad would be now usable (but there still some problems with suspend mode). Of course you can wait for the patch to be released upstream and backported to kernels from 4.15.4 or greater. you should check the progress of the bug if you want to know more about current investigations and imminent full fix. Regards, Vivien.
I confirm I have the same problem too on my Asus GL503VD (with BIOS up-to-date too). The bug is present on all the Linux systems I've tried, here is the list: * Ubuntu 17.10 * Xubuntu 16.04 * Linux Mint 18.3 * Antergos * Solus 3 GNOME Regards, Clément Nerma.
Same problem in ASUS D541N.
Created attachment 283983 [details] dmidecode
*** This bug has been marked as a duplicate of bug 203995 ***
I don't think this is a duplicate of #203995 and I don't think high CPU usage is related to slow/laggy behavior as stated in the report. After years of experience it just seems the *nix Elan drivers just don't work very well. I see no reason to mark this bug as a duplicate of 203995. If somebody in this thread had said, "oh! there's the IRQ storm in such-and-such attachment", then OK -- or if 203995 had said more about ELAN touchpads, then OK, but 203995 says nothing about ELAN. Maybe there was a discussion behind-the-scenes that drove the action to mark duplicate. https://bugzilla.redhat.com/show_bug.cgi?id=1543769 is closer to this problem and yet is still not resolved as it claims (see that thread's comments).
https://bugzilla.kernel.org/buglist.cgi?bug_status=__open__&content=elantech&list_id=1074017&order=Importance&query_format=specific shows a list of apparently repeated problems with ELAN mouse/touchpads which may indicate a class of problems with this driver that have never been properly resolved.
(In reply to fbeachler from comment #28) > I don't think this is a duplicate of #203995 and I don't think high CPU > usage is related to slow/laggy behavior as stated in the report. After years > of experience it just seems the *nix Elan drivers just don't work very well. > > I see no reason to mark this bug as a duplicate of 203995. If somebody in > this thread had said, "oh! there's the IRQ storm in such-and-such > attachment", then OK -- or if 203995 had said more about ELAN touchpads, > then OK, but 203995 says nothing about ELAN. Maybe there was a discussion > behind-the-scenes that drove the action to mark duplicate. In the bug opener it clearly states that CPU load is high due to IRQ storm. But since reporter kept silent I eager think that this is indeed a dup and it's fixed. In any case, they may reopen if it's not the case. P.S. There are patches in mainline kernel for many thing happened lately. In there is even patch to support SMBus 3.0 data length which helps for some touch pads, but there are issues that prevents half of the series to go.
Created attachment 293175 [details] attachment-7701-0.html Thank you for the reply. This helps clarify the mark as duplicate action. Thanks again for your help and work! On Fri, Oct 23, 2020, 5:10 PM <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=198473 > > --- Comment #30 from Andy Shevchenko (andy.shevchenko@gmail.com) --- > (In reply to fbeachler from comment #28) > > I don't think this is a duplicate of #203995 and I don't think high CPU > > usage is related to slow/laggy behavior as stated in the report. After > years > > of experience it just seems the *nix Elan drivers just don't work very > well. > > > > I see no reason to mark this bug as a duplicate of 203995. If somebody in > > this thread had said, "oh! there's the IRQ storm in such-and-such > > attachment", then OK -- or if 203995 had said more about ELAN touchpads, > > then OK, but 203995 says nothing about ELAN. Maybe there was a discussion > > behind-the-scenes that drove the action to mark duplicate. > > In the bug opener it clearly states that CPU load is high due to IRQ storm. > But since reporter kept silent I eager think that this is indeed a dup and > it's > fixed. > > In any case, they may reopen if it's not the case. > > P.S. There are patches in mainline kernel for many thing happened lately. > In > there is even patch to support SMBus 3.0 data length which helps for some > touch > pads, but there are issues that prevents half of the series to go. > > -- > You are receiving this mail because: > You are on the CC list for the bug.