Could be a good suggestion, but personally I do not use unverified software.
It does include touchpads. For a while I was using āacpi_osi=! acpi_osi=linuxā on my Dell laptop kernel command-line (to eliminate 100ās of ACPI error messages), but with a recent update touchpad stopped working. I removed the ACPI entries a couple days ago and so far no issues.
Three commands are exactly equivalent.
All write the output to /boot/grub2/grub.cfg
grub2-mkconfig -o /boot/grub2/grub.conf writes directly to the target
grub2-mkconfig -o /etc/grub2.cfg a link to the same target
grub2-mkconfig -o /etc/grub2-efi.cfg a link to the same target
$ ls -l /etc/grub2*
lrwxrwxrwx. 1 root root 22 Mar 9 19:00 /etc/grub2.cfg -> ../boot/grub2/grub.cfg
lrwxrwxrwx. 1 root root 22 Mar 9 19:00 /etc/grub2-efi.cfg -> ../boot/grub2/grub.cfg
I have been looking into this issue myself a bit - heres a bugzilla link 219799 ā ELAN1206 touchpad regression in kernel 6.9 - do let me know if anyone has any suggestions or if you had any progress fixing it.
I know that this isnāt a new issue, but, assuming you havenāt sorted it out completely, did you ever try to learn if the kernel was seeing your touchpad in the first place? I think itās possible for a device we think of as Touchpad to be identified as both a mouse and a touchpad simultaneously.
What do you see if you use sudo lshw | less then search for touchpad? (Note: You may need to ensure that in the paging program, less, case is ignored in searches; you can ensure this by toggling with ā-iā while in less.)
If itās there, you should see a line in the output of sudo journalctl -b 0 that with the same touchpad device in a line with kernel: input: in it. Output from journalctl automagically goes to the paging program less by default. So, again, check that case is ignored in your less searches for journalctl.
Yeah. The touchpad is recognized. basically what seems to be going on is the i2c-designware driver is taking too long to transfer events from i2c-hid or something like that when using IDMA. So essentially theres a timeout in the input code that sends a TRACKING_ID -1 if a response hasnt been read in 100 ms, which the touchpad will interpret as saying that theres no finger on the pad, even when there is. This timeout is being hit constantly. This then causes libinput to send a constant stream of BUTTON_TOUCH 0 events, and the cycle continues when you continue moving your finger across the touchpad, which causes none of the events to actually be interpreted by libinput. Thats why if you run evtest it will show all of the correct events except the extra TRACKING_ID -1 and such, but if you run libinput debug-events it will only show events not related to cursor position.
I donāt have evtest installed, but I took a look at the man page from ArchLinux.org, and saw this:
If evtest does not show any events even though the device is being used, the device may be grabbed by a process (EVIOCGRAB). This is usually the case when debugging a synaptics device from within X. VT switching to a TTY or shutting down the X server terminates this grab and synaptics devices can be debugged.
Is any of that business relevant to your situation?
Unfortunately no - evtest is showing events libinput isnt
Has anyone solved this issue? i am facing the same.
Making sure you're not a bot! for updates on progress fixing.
I have to do the latest debugging steps the kernel devs recommended but im going to be honest its driving me insane. I think theres a compatibility issue with the touchpad (obviously im not an expert in this stuff so I could be wrong). ASUS has been absolutely useless in assisting, I asked them for any technical documentation they could provide that may assist with determining if its a compatibility issue, which they declined to provide any. Nor would they provide any contact information from someone who has knowledge of the technical details of the touchpad. Honestly im pretty disappointed in ASUS support on this one, absolutely terrible experience. Linux kernel devs have been really helpful though in trying to debug this, but we havent figured it out yet. Ive been a little busy so I havent had a chance to go through their latest debugging steps, planning on doing so this week. Theres a āfixā somewhere here: ASUS UX564EH_Q528EH ELAN Touchpad detected but cannot move cursor. / Kernel & Hardware / Arch Linux Forums but it doesnt actually fix the issue and it does have some performance effects. It does make the touchpad work though (its just not a complete fix to me though). Im not really sure personally if its going to be able to be fixed but im definitely going to try a little more before giving up and just getting a different laptop lol.
Just wanted to note that my ELAN touchpad is working again as of yesterday, and it originally broke around mid-July or early August. I tried to follow juanfiboās guide from the Arch forums, but never got it to work, so itās probably not that (plus the forum seems to be talking about a different model touchpad).
ELAN0524:01 04F3:3215 Mouse and ELAN0524:01 04F3:3215 Touchpad are reported from libinput, although I donāt remember if the mouse used to show up in libinput previously. The touchpad certainly used to show up. I didnāt know how to troubleshoot it properly so I gave up and stuck with my USB mouse anyway.
Iām on kernel 6.16.5, and using Plasma
Hereās the output of journalctl -b -g hid
Sep 14 13:22:31 fedora kernel: hid: raw HID events driver (C) Jiri Kosina
Sep 14 13:22:31 fedora kernel: usbcore: registered new interface driver usbhid
Sep 14 13:22:31 fedora kernel: usbhid: USB HID core driver
Sep 14 13:22:31 fedora kernel: hid-generic 0003:046D:C548.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:00:14.0-6/input0
Sep 14 13:22:31 fedora kernel: hid-generic 0003:046D:C548.0002: input,hidraw1: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:14.0-6/input1
Sep 14 13:22:31 fedora kernel: hid-generic 0003:046D:C548.0003: hiddev96,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-6/input2
Sep 14 13:22:31 fedora kernel: hid-generic 0018:04F3:3215.0004: input,hidraw3: I2C HID v1.00 Mouse [ELAN0524:01 04F3:3215] on i2c-ELAN0524:01
Sep 14 13:22:31 fedora kernel: hid-multitouch 0018:04F3:3215.0004: input,hidraw3: I2C HID v1.00 Mouse [ELAN0524:01 04F3:3215] on i2c-ELAN0524:01
Sep 14 17:22:35 fedora kernel: input: Intel HID events as /devices/platform/INTC1070:00/input/input15
Sep 14 17:22:35 fedora kernel: intel-hid INTC1070:00: platform supports 5 button array
Sep 14 17:22:35 fedora kernel: input: Intel HID 5 button array as /devices/platform/INTC1070:00/input/input16
Sep 14 17:22:35 fedora kernel: Modules linked in: btusb snd_hwdep processor_thermal_device_pci btrtl snd_seq processor_thermal_device btintel uvcvideo irqbypass processor_thermal_wt_hint snd_seq_device btbcm rapl libarc4 uvc>
Sep 14 17:22:35 fedora kernel: drm_suballoc_helper gpu_sched drm_gpuvm drm_exec drm_gpusvm nvme i915 i2c_algo_bit drm_buddy ttm polyval_clmulni drm_display_helper ghash_clmulni_intel hid_multitouch sha512_ssse3 thunderbolt >
Sep 14 17:22:36 fedora systemd-logind[1094]: Watching system buttons on /dev/input/event11 (Intel HID events)
Sep 14 17:22:36 fedora systemd-logind[1094]: Watching system buttons on /dev/input/event12 (Intel HID 5 button array)
Sep 14 17:23:10 fedora NetworkManager[1265]: <info> [1757884990.1066] Config: added 'psk' value '<hidden>'
Sep 14 20:46:14 fedora NetworkManager[1265]: <info> [1757897174.0112] Config: added 'psk' value '<hidden>'
Sep 14 22:11:01 fedora kernel: i2c_hid_acpi i2c-ELAN0524:01: i2c_hid_get_input: incomplete report (14/65280)
Sep 14 22:11:03 fedora NetworkManager[1265]: <info> [1757902263.9584] Config: added 'psk' value '<hidden>'
Sep 14 23:28:52 fedora NetworkManager[1265]: <info> [1757906932.8009] Config: added 'psk' value '<hidden>'
Sep 15 01:50:08 fedora NetworkManager[1265]: <info> [1757915408.1746] Config: added 'psk' value '<hidden>'
Sep 15 11:37:12 fedora NetworkManager[1265]: <info> [1757950632.0969] Config: added 'password' value '<hidden>'