Hello,
I have a keyboard problems after upgrading the last kernel.
Some keys stop working from time to time. For example “r” or “o” or “Shift” that happens occasionally. And forced me to disassemble the laptop and blow all the dust inside with no success. Everything works fine when I stat the older kernel that I have. 7.0.34.
Any suggestions?
for me intermittent r/o/shift after a kernel bump is usually hid/atkbd on the new one.
id try:
-stay on 7.0.34 for daily till a newer lands
-after a dead key: dmesg -T | grep -iE ‘hid|i8042|atkbd|keyboard’
-libinput debug-events while u hit the stuck keys
i8042.reset or i8042.nopnp on the cmdline has unfucked laptop boards for me b4.
I already tried to dump events. When there is no key there is no event at all.
It’s interesting that this happens from time to time and then disappears as a problem.
Afterwards can happen again in some time.
That actually happens on the old kernel too. Just not so often.
if libinput shows nothing when the key is dead then the press never hit the input stack.
id try next:
-dmesg -w in a terminal and wait for a dead-key stretch, watch for usb/i8042 resets
-journalctl -b -k | grep -iE ‘usb.*(disconnect|reset)|i8042|atkbd’
-boot once with usbcore.autosuspend=-1 and see if the gaps shrink
Have you tried logging output from evtest? It’s a layer lower than libinput, so in case the fault is with libinput not correctly reading events, this would still show the event.
I try now but I get those losses of key pressings and I don’t see errors in the console at all.
Also I noticed that some of those at some point appear twice on one pressing. Looks quite strange.
I am also facing the same issue. The number row on my USB keyboard stops working and then works fine after 4-5 seconds. Tried evtest but it also doesnt show any event. Also checked dmesg -w at the same time but there was no related logs.
Although there were some entries stating following, but I do not think it is related.
perf: interrupt took too long (3988 > 3986), lowering kernel.perf_event_max_sample_rate to 50000
If evtest doesn’t show any events during the drops, the hardware press isn’t reaching the input subsystem. Check dmesg for hid, atkbd, or i8042 errors right after a key fails, and test with libinput debug-events to confirm if the kernel layer is dropping it. You can also test booting with i8042.reset or i8042.nopnp kernel parameters to see if the controller behavior stabilizes.