Keyboard issues

tx · 2025-10-24 12:09:08

I forgot that I also have a different problem. Sometimes (probably about once a month or two) the built-in laptop keyboard stops working unexpectedly. Could it be somehow related, or is it definitely a hardware issue? How to debug it?

seth · 2025-10-24 13:00:05

Does the keyboard sometimes also expectedly stop working
Do you have a journal covering such case? (Though I very much doubt that's related to PSR)

tx · 2025-10-24 18:44:39

I don't think there is anything useful in the log, but here it is: https://0x0.st/K2u9.txt
I don't know the exact time, but I rebooted a few minutes after the freeze, so it happened at around 08:20.

I installed a GUI keyboard and set up mouse binding to spawn it to try and debug it next time it happens.
Any ideas what could be causing it?
Which commands to try and run?
I think maybe looking at raw keyboard events of some sort to test whether the kernel gets signal from it?

Last edited by tx (2025-10-24 18:45:42)

seth · 2025-10-24 19:50:10

Oct 24 08:21:16 txT14Arch systemd[1]: Started Getty on tty2.
Oct 24 08:21:16 txT14Arch systemd-logind[858]: Removed session 4.
Oct 24 08:21:18 txT14Arch slop[11139]: pam_unix(slop:session): session opened for user tx(uid=1000) by tx(uid=0)
Oct 24 08:21:18 txT14Arch systemd-logind[858]: New session '5' of user 'tx' with class 'user' and type 'tty'.
Oct 24 08:21:18 txT14Arch systemd[1]: Started Session 5 of User tx.

meaning the keyboard stops to work in your dwm session, but not in general (you can still switch the TTY, login and shutdown)?

Also

Oct 24 08:10:07 txT14Arch sudo[3933]:       tx : TTY=pts/1 ; PWD=/home/tx ; USER=root ; COMMAND=/usr/bin/pacman -S qtvkbd
Oct 24 08:10:23 txT14Arch sudo[3970]:       tx : TTY=pts/1 ; PWD=/home/tx ; USER=root ; COMMAND=/usr/bin/pacman -S qt6-virtualkeyboard
Oct 24 08:11:55 txT14Arch sudo[5244]:       tx : TTY=pts/1 ; PWD=/home/tx ; USER=root ; COMMAND=/usr/bin/pacman -S --config /etc/pacman.conf -- extra/libxp extra/imake extra/xaw3d
Oct 24 08:11:58 txT14Arch sudo[5280]:       tx : TTY=pts/1 ; PWD=/home/tx ; USER=root ; COMMAND=/usr/bin/pacman -D -q --asdeps --config /etc/pacman.conf -- libxp imake xaw3d
Oct 24 08:12:01 txT14Arch sudo[9390]:       tx : TTY=pts/1 ; PWD=/home/tx ; USER=root ; COMMAND=/usr/bin/pacman -U --config /etc/pacman.conf -- /home/tx/.cache/yay/xvkbd/xvkbd-4.1-1-x86_64.pkg.tar.zst /home/tx/.cache/yay/xvkbd/xvkbd-debug-4.1-1-x86_64.pkg.tar.zst
Oct 24 08:12:03 txT14Arch sudo[9397]:       tx : TTY=pts/1 ; PWD=/home/tx ; USER=root ; COMMAND=/usr/bin/pacman -D -q --asdeps --config /etc/pacman.conf -- xvkbd-debug
Oct 24 08:12:03 txT14Arch sudo[9401]:       tx : TTY=pts/1 ; PWD=/home/tx ; USER=root ; COMMAND=/usr/bin/pacman -D --asexplicit -q --config /etc/pacman.conf -- xvkbd

you seem to have installed a bunch or virtual keyboards beforehand?

I think maybe looking at raw keyboard events of some sort to test whether the kernel gets signal from it?

The lowest layer would be "sudo evtest".

tx · 2025-10-24 20:16:11

Sorry. I posted a wrong log... It's the boot after the freeze, hence the pacman messages...
I posted it in the morning, apparently I wasn't awake yet.

Anyway, here's the correct one (no idea how I didn't notice given that the correct log is from yesterday...): https://0x0.st/K2SI.txt
You can even see when I pressed the power key to shut down:

Oct 23 20:54:09 txT14Arch systemd-logind[845]: Power key pressed short.

I definitely tried to change TTY and it didn't work.

seth · 2025-10-24 21:06:41

Oct 23 20:40:20 txT14Arch sudo[10103]:       tx : TTY=pts/1 ; PWD=/home/tx/srcs/rtcqs ; USER=root ; COMMAND=/usr/bin/pacman -S tk
Oct 23 20:40:20 txT14Arch sudo[10103]: pam_unix(sudo:session): session opened for user root(uid=0) by tx(uid=1000)
Oct 23 20:40:23 txT14Arch sudo[10103]: pam_unix(sudo:session): session closed for user root
Oct 23 20:41:06 txT14Arch bluetoothd[2503]: profiles/audio/media.c:parse_int64_metadata() expected DBUS_TYPE_INT64 got DBUS_TYPE_UINT64
Oct 23 20:41:50 txT14Arch rtkit-daemon[1632]: Supervising 9 threads of 5 processes of 1 users.
Oct 23 20:41:50 txT14Arch rtkit-daemon[1632]: Supervising 9 threads of 5 processes of 1 users.
Oct 23 20:41:59 txT14Arch rtkit-daemon[1632]: Supervising 9 threads of 5 processes of 1 users.
Oct 23 20:41:59 txT14Arch rtkit-daemon[1632]: Supervising 9 threads of 5 processes of 1 users.
Oct 23 20:41:59 txT14Arch rtkit-daemon[1632]: Supervising 9 threads of 5 processes of 1 users.
Oct 23 20:41:59 txT14Arch rtkit-daemon[1632]: Supervising 9 threads of 5 processes of 1 users.
Oct 23 20:42:17 txT14Arch rtkit-daemon[1632]: Supervising 9 threads of 5 processes of 1 users.
Oct 23 20:42:17 txT14Arch rtkit-daemon[1632]: Supervising 9 threads of 5 processes of 1 users.
Oct 23 20:43:00 txT14Arch rtkit-daemon[1632]: Supervising 9 threads of 5 processes of 1 users.
Oct 23 20:43:00 txT14Arch rtkit-daemon[1632]: Supervising 9 threads of 5 processes of 1 users.
Oct 23 20:44:21 txT14Arch bluetoothd[2503]: profiles/audio/media.c:parse_int64_metadata() expected DBUS_TYPE_INT64 got DBUS_TYPE_UINT64
Oct 23 20:44:28 txT14Arch bluetoothd[2503]: profiles/audio/media.c:parse_int64_metadata() expected DBUS_TYPE_INT64 got DBUS_TYPE_UINT64
Oct 23 20:44:33 txT14Arch bluetoothd[2503]: profiles/audio/media.c:parse_int64_metadata() expected DBUS_TYPE_INT64 got DBUS_TYPE_UINT64
Oct 23 20:44:37 txT14Arch bluetoothd[2503]: profiles/audio/media.c:parse_int64_metadata() expected DBUS_TYPE_INT64 got DBUS_TYPE_UINT64
Oct 23 20:47:34 txT14Arch rtkit-daemon[1632]: Supervising 9 threads of 5 processes of 1 users.
Oct 23 20:47:34 txT14Arch rtkit-daemon[1632]: Supervising 9 threads of 5 processes of 1 users.
Oct 23 20:48:22 txT14Arch rtkit-daemon[1632]: Supervising 9 threads of 5 processes of 1 users.
Oct 23 20:48:22 txT14Arch rtkit-daemon[1632]: Supervising 9 threads of 5 processes of 1 users.
Oct 23 20:52:51 txT14Arch systemd[1]: tmp-.mount_appimaJSALC2.mount: Deactivated successfully.
Oct 23 20:54:09 txT14Arch systemd-logind[845]: Power key pressed short.

At 20:40:20 you run sudo, then there're some bluetooth audio events at 20:52:51 some appimage terminates(?) and 80s later you're pushing the power button.

Oct 23 09:28:03 txT14Arch kernel: input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
Oct 23 09:28:03 txT14Arch kernel: hid-generic 0003:046D:C52B.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:c3:00.3-1/input0
Oct 23 09:28:04 txT14Arch kernel: input: keyd virtual keyboard as /devices/virtual/input/input33
Oct 23 09:28:04 txT14Arch systemd-logind[845]: Watching system buttons on /dev/input/event3 (AT Translated Set 2 keyboard)
Oct 23 09:28:04 txT14Arch systemd-logind[845]: Watching system buttons on /dev/input/event15 (keyd virtual keyboard)
Oct 23 09:28:04 txT14Arch keyd[840]: DEVICE: match    0001:0001:09b4e68d  /etc/keyd/default.conf        (AT Translated Set 2 keyboard)

there's the built-in keyboard, some logitech dongle and keyd
Have you tried to remove the logitech dongle and/or attach an external keyboard when the internal one breaks?

schard · 2025-10-24 21:22:03

Mod note: Split from https://bbs.archlinux.org/viewtopic.php?id=309622

@tx In the future, please open a new thread for separate issues.

tx · 2025-10-24 22:03:54

I closed appimage that was on the screen using the mouse just in case there was a problem with it.
Then, for a minute, tried switching TTY, pressing SysRqs.
Finally, rebooted due to not having any other options.

Bluetooth error is definitely unrelated as it happens a lot without any visible effects. Grepping the entire journal (which is a month long) there are 1164 such bluetooth messages (and this is the only keyboard issue during this time).
The only bluetooth device I use is headphones, and there doesn't seem to be any problem with the playback which is why I ignore this error.

Logitech dongle is for a mouse, not sure why it says "USB HID v1.11 Keyboard". I guess Logitech uses same dongle for both so it always shows as keyboard and mouse?
That's the only USB device connected to the laptop.
I do not have any external keyboard, unfortunately.
Should I try detaching dongle anyway?

@schard i did not create a new thread because I wasn't entirely sure whether the issue is unrelated.

Last edited by tx (2025-10-24 22:10:13)

seth · 2025-10-25 08:25:23

Should I try detaching dongle anyway?

Yes.

I do not have any external keyboard, unfortunately.

Can you get one? Or ssh into the system?
There's no sign of keyboard use after closing the appimage (sysrq would leave traces) meaning the kernel no longer gets events from that device.
Does it work immediately after the reboot?

It would be useful to test reloading the atkbd/i8042 modules.

tx · 2025-10-25 13:47:37

Can you get one? Or ssh into the system?

I can ssh.

Does it work immediately after the reboot?

Yes.

It would be useful to test reloading the atkbd/i8042 modules.

Both of them are built-in. How to build kernel with these modules being loadable instead?

seth · 2025-10-25 15:26:08

The LTS kernel has them (still?) as extra modules, otherwise you'd have to https://wiki.archlinux.org/title/Kernel … ild_system and change the config there.
If you can, try to get access to an external keyboard - there's probably no point in trying to reload the modules if the input is failing somewhere else.

tx · 2025-10-25 16:22:32

So I have to build a kernel myself, there is no way of just changing config instead?
Do you think it's possible to use phone as a bluetooth keyboard instead of an external one? There seem to be apps that do this. I'm just not sure whether it will truly act as an external keyboard.

seth · 2025-10-25 16:28:06

So I have to build a kernel myself, there is no way of just changing config instead?

seth wrote:

The LTS kernel has them (still?) as extra modules

otherwise no, you cannot runtime make internal modules external.

Do you think it's possible to use phone as a bluetooth keyboard

Likely but you want as little variables as possible and bluetooth is already suspicious enough - it would be better if you could just plug a keyboard when the internal one fails.

tx · 2025-10-25 16:37:30

I'm sorry I don't own an external keyboard and I won't buy it just to debug this.
Okay, I'll run LTS kernel.

So in case it freezes, I will:
1. Try disconnecting USB dongle
2. Use ssh or on-screen keyboard to reload modules

What other commands should I run?
If it actually disconnected, it would be logged in journal, so it is still "connected".
Try evtest just in case?
Should I still try bluetooth keyboard? I mean, it's better than nothing?

seth · 2025-10-25 16:43:42

If it actually disconnected, it would be logged in journal, so it is still "connected".
Try evtest just in case?

There's no indication for any keyboard failure or action in the log - if the sysrq does not get registered, neither will evtest (you may still try, but don't hold your breath)
Likewise you can of course attach a BT keyboard, just if "it doesn't work" that won't tell all that much.

For the Logitech dongle, I'd actually try to run the system w/o for a while and see whether the keyboard still drops out (if yes, it's unlikely related at all - if no, well…)

tx · 2025-10-25 16:53:27

There's no indication for any keyboard failure or action in the log

I just thought that maybe I should list devices after it stops working in case something gets added/removed, but that should be in the log, right?

I'll consider running without the mouse dongle.

Well, if there's nothing else to do, I guess I'm going to wait and see. As it usually happens every month or so, it will be a while until I reply.

Do you think not rebooting will increase the chance of it happening? I usually reboot every day or so, maybe I should try doing it less?

Last edited by tx (2025-10-25 16:56:05)

seth · 2025-10-25 18:26:05

You reboot every day and once a month you're running into this after like 10½ hours? Or does the uptime not matter?

Oct 23 09:28:03 txT14Arch kernel: i8042: Warning: Keylock active

Any chance you're just activating the Fn-lock or some lenovo specific keyboard lock or apparently an a11y mode on Fn+shift - https://superuser.com/questions/1866485 … e-keyboard (includes cute pussy)

tx · 2025-10-25 19:08:40

According to the user guide for my model (https://download.lenovo.com/pccbbs/mobi … nux_ug.pdf) there isn't anything like that.

Here's what all combinations of Fn+Key do according to `keyd monitor`:
Fn+Esc and Fn+Space don't send keyboard event
Fn+PrtSc produces the following log entry "ERROR: unsupported evdev code: 0x27a"
Others from the manual work as expected
Fn+Right shift (from your link) print "prog3 up/down". I assume it means programmable key? anyway, it doesn't do anything.
Other undocumented keys don't do anything, no event, no error, and keyboard still works.

EDIT: freezes are relatively random but I think out of around 10 I've had in the past year most were after around 6-8 hours of uptime.

Last edited by tx (2025-10-25 19:09:53)

seth · 2025-10-26 10:23:30

The Fn-lock stuff (Fn+Esc should™ trigger this??) and possible keyboard locks will not generate events in the OS, they're pure HW features.

tx · 2025-10-26 13:57:31

FnLock only does what it is supposed to do by swapping F1-F12 keys and their special functions, the rest of the keyboard is completely unaffected. Moreover, there's an LED when it's turned on, so I would have noticed it.

One more thing I will try when it freezes is pressing these key combinations that should be handled by keyboard (either FnLock to enable the LED, or Fn+Space to turn on keyboard backlight).
If they don't work, the problem is with the keyboard itself. Otherwise, the keyboard controller gets the keys but they don't reach the kernel. Correct?

seth · 2025-10-26 16:07:49

If they don't work, the problem is with the keyboard itself. Otherwise, the keyboard controller gets the keys but they don't reach the kernel. Correct?

You'd have to try w/ the keyboard modules unloaded to know what behavior to expect at this moment.

tx · 2025-10-26 16:10:33

Just tried. After removing the modules keyboard stopped working, but the keys still worked.

Arch Linux

#1 2025-10-24 12:09:08

Keyboard issues

#2 2025-10-24 13:00:05

Re: Keyboard issues

#3 2025-10-24 18:44:39

Re: Keyboard issues

#4 2025-10-24 19:50:10

Re: Keyboard issues

#5 2025-10-24 20:16:11

Re: Keyboard issues

#6 2025-10-24 21:06:41

Re: Keyboard issues

#7 2025-10-24 21:22:03

Re: Keyboard issues

#8 2025-10-24 22:03:54

Re: Keyboard issues

#9 2025-10-25 08:25:23

Re: Keyboard issues

#10 2025-10-25 13:47:37

Re: Keyboard issues

#11 2025-10-25 15:26:08

Re: Keyboard issues

#12 2025-10-25 16:22:32

Re: Keyboard issues

#13 2025-10-25 16:28:06

Re: Keyboard issues

#14 2025-10-25 16:37:30

Re: Keyboard issues

#15 2025-10-25 16:43:42

Re: Keyboard issues

#16 2025-10-25 16:53:27

Re: Keyboard issues

#17 2025-10-25 18:26:05

Re: Keyboard issues

#18 2025-10-25 19:08:40

Re: Keyboard issues

#19 2025-10-26 10:23:30

Re: Keyboard issues

#20 2025-10-26 13:57:31

Re: Keyboard issues

#21 2025-10-26 16:07:49

Re: Keyboard issues

#22 2025-10-26 16:10:33

Re: Keyboard issues

Board footer