You are not logged in.
It's not the first time, but its getting annoying lately
Touchpad (the cursor) stops working randomly; The fact is keyboard works normally, and clicking button also works, I don't remember if taps work; no gestures, no movement.
"affected" journal: https://paste.c-net.org/AbruptDolphins although I couldn't find anything wrong
I'm on Hyprland, and I don't remember experiencing this when I was using KDE or Gnome
sometimes just opening Kitty(terminal) solves the issue, or running hyprctl reload solves the issue, or sometimes I have to log out and log in
it's not reproducible, sometimes w/o doing anything it just gets working
on the journal there are TLP spam, I disabled it while trying to solve a previous issue; however I now uninstalled it. The behavior was before I setup TLP or AutoCPU-Freq.
So my question is: How do I make my touchpad "more" reliable on Hyprland? I hate this inconsistency ![]()
└─$ cat /proc/bus/input/devices | grep -A5 -i touchpad
N: Name="ELAN0708:00 04F3:30A0 Touchpad"
P: Phys=i2c-ELAN0708:00
S: Sysfs=/devices/platform/AMDI0010:01/i2c-0/i2c-ELAN0708:00/0018:04F3:30A0.0001/input/input13
U: Uniq=
H: Handlers=event8 mouse1
B: PROP=1└─$ hyprctl version
Hyprland 0.54.3 built from branch v0.54.3 at commit 521ece463c4a9d3d128670688a34756805a4328f clean (version: bump to 0.54.3).
Date: Fri Mar 27 18:17:50 2026
Tag: v0.54.3, commits: 7014
Libraries:
Hyprgraphics: built against 0.5.1, system has 0.5.1
Hyprutils: built against 0.13.0, system has 0.13.1
Hyprcursor: built against 0.1.13, system has 0.1.13
Hyprlang: built against 0.6.8, system has 0.6.8
Aquamarine: built against 0.11.0, system has 0.11.0
Version ABI string: 521ece463c4a9d3d128670688a34756805a4328f_aq_0.11_hu_0.13_hg_0.5_hc_0.1_hlg_0.6
no flags were setEdit:
I hope this helps
https://paste.c-net.org/MundaneObtained
Last edited by 5hridhyan (2026-05-12 13:49:43)
Online
I sometimes encounter similar issue on Dell Latitude 5400, also touchpad on I²C bus:
N: Name="DELL08B8:00 0488:121F Touchpad"
P: Phys=i2c-DELL08B8:00
S: Sysfs=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-1/i2c-DELL08B8:00/0018:0488:121F.0001/input/input15Sometimes cursor starts to slow down for few seconds before becoming completely unresposive.
However, I don't use Hyprland, in my case neither Xorg restart or logout/login doesn't help, only reboot recovers it. The same behavior observed in VT with gpm as well.
Perhaps in your case it recovers because of some kind of reinitialization.
I'm pretty sure it's a hardware of firmware bug. Sometimes I can reproduce it by placing AC adapter wire close to another noisy power supply unit. Haven't found solution yet.
Last edited by dimich (2026-05-12 14:40:07)
Offline
There're unfortunately no timestamps in the hyprland log - does the touchpad still generate the expected input in "libinput debug-events" or "evtest"?
There's an occasional "palm detected (edge)", can you reproduce this when doing some trap/delt/bicep training and lifting your paws so they won't touch the pad for sure?
Offline
@dimich, Yes I remember I rebooted once because of this issue, but it was like 1 in a 100000th time...
@seth I really tried hard to reproduce and test w/ libinput, I'm still not being able to reproduce it
I suspect my Keyboard is contributing it, my keyboard "has" a history of Ghost inputs, like if pressed and released a key, the key still keeps inputting on the screen; again this is also not reproducible, Im suspecting it because I have `disable_while_typing = true`, but I don't know how will it explain using other keybinds to open terminal or run commands
also I remember my palms paws were at my textbook
although I'm like a lazy cat, my paws are almost always lying on it, but at the time, my paws weren't resting I was trying to move the cursor
When it happens again I'll run libinput or evtest, and bump this thread w/ relevant output and observations(if any) ![]()
Online
It is interesting problem. I am running KDE across all my distro set. On Dell XPS 2026 I have installed Endeavouros and CachyOS (v7.x) couple months ago and it works fine from the beginning. Different distros, different kernels, works ok. Yesterday I installed the fresh Endeavouros and the problem happened. Touchpad (glass haptic) stopped emulating clicking, stopped recognizing gesture/movement. Then I've installed stock vanilla Arch distro (+KDE) - it randomly stopped working again (well, it is expected) On previously installed distro - everything still works. Very annoying.
Offline
@BigMoose there's some threads about touchpads not working at all which might be linked to recent kernels, but 5hridhyan's problem is that the touchpads refuses operation midway through a session.
Do you have the same problem w/ the LTS kernel or some older 6.19 one from the https://wiki.archlinux.org/title/Arch_Linux_Archive ?
(You may downgrade the kernel in isolation, it's very self contained and unless you're crossing major toolchain breaks that happen once in a blue moon or downgrade into the pre-zstd era (you'll not be able to decompress the initramfs generated by default), the (slightly) older kernel will boot fine.
Offline
@seth,
Agreed, the original problem is different. In my case it happened most common after reboot. However, one time it starts working suddenly and then stopped again. Now, interestingly, it starts working after logout and login back.
On my new Panther Lake laptop (XPS 16), for 6.18 LTS or old 6.19 I have more HW issues, my laptop starts working properly from Linux 7.0. The sighting is - the problem does not exist for Linux A and Linux B, installed couple month ago, but consistently shows up for freshly installed same Linux A and Linux B.
Offline
the problem does not exist for Linux A and Linux B, installed couple month ago, but consistently shows up for freshly installed same Linux A and Linux B
They all were using 7.x kernels? (Arch moved to 7.0.2 on Apr 27, 2026)
If it's not the kernel, try to downgrade systemd - https://bbs.archlinux.org/viewtopic.php … 2#p2299842
Offline
the problem does not exist for Linux A and Linux B, installed couple month ago, but consistently shows up for freshly installed same Linux A and Linux B
They all were using 7.x kernels? (Arch moved to 7.0.2 on Apr 27, 2026)
Yes. I tried stock linux (now it is 7.0.10), xanmod/zen (7.0.10), and linux-cachyos-rc1.4x, I have started on linux-cachy-rc7.0x in March and also installed stock linux-7.0x when it became available (my main daily driver is endeavouros, just recently drifted also to vanilla Arch)
Offline
If it's not the kernel, try to downgrade systemd - https://bbs.archlinux.org/viewtopic.php … 2#p2299842
Same systemd works on previously installed kernels. And newer systemd version is better/faster. And I have workaround that works for me, just a bit annoying extra steps (logout/login). Just curious on the strange, sometime random, behavior and its root-cause. And thoughts on immutable linux distros ![]()
Offline
newer systemd version is better/faster. And I have workaround that works for me, just a bit annoying extra steps (logout/login)
If restarting the display server reliably restores the device you're probably just facing a race condition where the graphical target starts before that hardware has initialized.
Try to artificially delay the display server (session login)
Offline