You are not logged in.
Hi everyone. I'm using Arch on a ThinkPad T14s Gen 4 (AMD). I'm having problems with the touchpad. It stop working randomly for a few seconds and sometimes feels sluggish and like it has a delay between the input and the movement of the cursor.
I tried looking in the wiki but hasn't found anything too similar. I tired unloading and reloading the psmouse module to no avail and tried setting i8042.nomux=1 as a kernel parameter but also to no avail. I'm not sure on how to diagnose the problem and will appreciate any help.
Last edited by JacoNIX97 (2026-01-28 08:11:12)
Offline
might just need replaced
Offline
Isn't there some steps to check if it's a hardware or software issue first? I'd really rather avoid replacing it, and the fact that is working most of the time makes me hope it's a software issue
Offline
journalctl -b | curl -F file=@- 0x0.stmight give us some hints
Offline
Isn't there some steps to check if it's a hardware or software issue first?
when the behavior feels odd, run and see what it shows, helps to narrow it down.
dmesg | grep -iE 'i2c|hid|touchpad|synaptics|elan'sudo libinput debug-eventsLast edited by 5hridhyan (2026-01-20 09:40:21)
Offline
The output of
journalctl -b | curl -F file=@- 0x0.stis in https://0x0.st/PKIK.txt
the result of
dmesg | grep -iE 'i2c|hid|touchpad|synaptics|elan'is empty
while
sudo libinput debug-eventsgives a command not found error (libinput is installed)
Offline
I installed libinput-tools to be able to run libinput debug-events but it started working normally and can't recreate the problem at the moment.
Offline
ok
input: SYNA8018:00 06CB:CE67 Mouse as /devices/platform/AMDI0010:01/i2c-1/i2c-SYNA8018:00/0018:06CB:CE67.0001/input/input29
input: SYNA8018:00 06CB:CE67 Touchpad as /devices/platform/AMDI0010:01/i2c-1/i2c-SYNA8018:00/0018:06CB:CE67.0001/input/input30
hid-generic 0018:06CB:CE67.0001: input,hidraw0: I2C HID v1.00 Mouse [SYNA8018:00 06CB:CE67] on i2c-SYNA8018:00
input: SYNA8018:00 06CB:CE67 Mouse as /devices/platform/AMDI0010:01/i2c-1/i2c-SYNA8018:00/0018:06CB:CE67.0001/input/input32
input: SYNA8018:00 06CB:CE67 Touchpad as /devices/platform/AMDI0010:01/i2c-1/i2c-SYNA8018:00/0018:06CB:CE67.0001/input/input33
hid-multitouch 0018:06CB:CE67.0001: input,hidraw0: I2C HID v1.00 Mouse [SYNA8018:00 06CB:CE67] on i2c-SYNA8018:00
Those lines confirm the device is detected and bound properly, so a hardware replacement does not look justified at this point.
Regarding the apparent “re-initialization” at boot: the duplicate entries at the same timestamp are expected for I²C HID devices. The touchpad exposes multiple interfaces (pointer + touch), and hid-generic is later complemented by hid-multitouch. This does not by itself indicate a failure or reset loop.
i sus a runtime power management / EC behavior.
some say to disable runtime PM for it
i2c_hid.disable_runtime_pm=1and some create udev rules to keep it awake and some reload modules when odd behavior
Last edited by 5hridhyan (2026-01-20 10:57:18)
Offline
Thanks. I'll try to add this kernel parameter and see if I incur again in the problem in the next few days.
Offline
I was able to replicate the problem, the issue is registered by libinput as a touchpad jump:
event8 - SYNA8018:00 06CB:CE67 Touchpad: kernel bug: Touch jump detected and discarded.
See https://wayland.freedesktop.org/libinput/doc/1.30.1/touchpad-jumping-cursors.html for detailsOffline
event8 - SYNA8018:00 06CB:CE67 Touchpad: kernel bug: Touch jump detected and discarded. See https://wayland.freedesktop.org/libinput/doc/1.30.1/touchpad-jumping-cursors.html for details
That aligns with an I²C-HID / power management issue.
libinput detecting and discarding jumps suggests bogus coordinates from the kernel driver rather than hardware failure
edit:
so yeah try that parameter and see if it works.....
Last edited by 5hridhyan (2026-01-20 11:08:45)
Offline
I tired the parameter but did0t work. Right now I'm running with it but still have the issue.
Offline
so disabling i2c_hid runtime PM did not resolve it, should'nt be a pure autosuspend issue.
libinput flags kernel-emitted touch jumps, the remaining suspects are AMD PMC / s2idle interactions or firmware timing.
try
mem_sleep_default=deep*this parameter tries `deep` instead of s2idle, I doubt it most modern hardware `deep` doesnt work or cause other issues on some hardware
testing another kernel (e.g. LTS).
if even that doesnt work, it's weird and replacing the touchpad wont help because same firmware/EC so from a kernel POV "ntg meaningfully changed"
but yeah Sometimes different hardware revisions have different firmware or work better with certain drivers. It's not entirely impossible that a hardware replacement could help, though unlikely.
EDIT:
does reloading modules make it normal? i mean for Synaptics (SYNA8018) , pmouse module reloading not helps in this case.
sudo modprobe -r hid_multitouch i2c_hid
sudo modprobe i2c_hid hid_multitouchlikely these but confirm it with
lsmod | grep -E "i2c_hid|hid_multitouch|synaptics"also I forgot to ask, since when did this issue started? after any specific updates?
https://pcsupport.lenovo.com/us/en/prod … -21f8-21f9
is it at latest BIOS/firmware version?
Last edited by 5hridhyan (2026-01-20 14:42:17)
Offline
I can't put the system in deep sleep as I have the kernel in lockdown mode.
I can't reload the kernel module i2c_hid with error
modprobe: FATAL: Module i2c_hid is in use.but reloading just the hid_multitouch module does not seem to be the solution as I get jumps in the logs (even though not noticeable as of now)
the lsmod command gives
hid_multitouch 36864 0
i2c_hid_acpi 12288 0
i2c_hid 45056 1 i2c_hid_acpiI'm not an avid touchpad user, I haven't noticed a correlation between a specific update and the problem arising but the first few days I had this laptop (it's pretty new) it worked without issues so I guess it's a strong possibility. I'm using GNOME if it can be part of the problem.
The system is at the latest version provided by fwupd
Offline
I'm using GNOME if it can be part of the problem.
gnome just been honest like it's not the cause, I forgot if I asked how is the behavior in a LTS kernel?
also "i2c_hid.reset=1" it just forces a reset in the init, likely wont help
it might be possible that anyone has a workaround or already reported to upstream.
so yeah wait for fixes/report it
i'll try my best to search a workaround *if there
edit:
as @system72 said replacing might help but it should be a different FRU (field replacement unit) revision which by luck have correct/updated firmware which handles a proper `runtime PM` correctly and, Even if Synaptics released a fix one or two months ago, the replacement part sitting in a warehouse might still have the "day one" buggy firmware.
Last edited by 5hridhyan (2026-01-20 14:47:37)
Offline
Thank you very much for the help. But a firmware update could possibly fix the issue if it's firmware related? For now I'll wait for the updated bios to come via fwupd as it seems to pertain power cycling issues in Linux, maybe it's related.
Offline
your welcome ![]()
But a firmware update could possibly fix the issue if it's firmware related?
Yes, but only if the issue is known to the vendor and addressed in a BIOS/EC update. In that case a firmware update can fix it completely.
Waiting for a BIOS update is still a reasonable choice. Lenovo typically delivers firmware updates either via fwupd on Linux or through their bootable update ISO/USB, depending on the model and update. After an update, it would be worth retesting to see if the touch jumps disappear.
Last edited by 5hridhyan (2026-01-20 15:38:27)
Offline
I noticed that the problem occurs more when the laptop is charging. Could it be an electrical problem?
Offline
uhm, no I guess, increased occurrence while charging points toward electrical noise or EC / power management behavior affecting the I²C-HID touchpad. but it shows it's I^2C/firmware timings are too sensitive
, and this might be the reason why it was giving invalid co-ordinates, is it same in diff plug points?
Last edited by 5hridhyan (2026-01-26 11:11:30)
Offline
There is a difference between power outlets. I noticed just today because I use this laptop mainly at work. I have the most problems in one particular room, and a a lot less in another. At home I'm having no problems at the moment. After writing the comment today I also tried unplugging a particular appliance in the room that gives the most problems (although it was turned off, it's a space heater) and it improved significantly the jumps in the touchpad. I reported this to a colleague and we'll be investigating the electrical issues further as we suspect something is not grounded correctly.
Offline
oh! ok then yeah *electrical noise, that said grounding issues can produce “phantom touches” or coordinate jumps, so it doesn’t reproduce at home and varies by outlet/room, this is not a software or touchpad hardware fault. Fixing grounding or isolating the noisy circuit should help. ![]()
Last edited by 5hridhyan (2026-01-27 19:37:21)
Offline
The laptop is also full metal body so that doesn't help I guess. Do you think this could cause long term issues to the touchpad?
Offline
No, this shouldn’t cause long-term damage to the touchpad.
you are experiencing/seeing interference affecting signal integrity, not electrical stress, and libinput discarding touch jumps means the device is behaving normally and staying within safe limits.
also a metal chassis is designed to be grounded and doesn’t harm the device; poor grounding just makes interference effects more noticeable. Once the grounding/noise issue is resolved, the touchpad should behave normally again without any lasting impact.
Last edited by 5hridhyan (2026-01-28 03:30:37)
Offline
Thanks for all the help then. Have a nice one!
Offline