Control key intermittently auto-pressing: Even without keyboard plugged in!

Ask Fedora
, , ,
1

Hi again, I thought I figured out an issue I was having with my keyboard last night. Turns out, it wasn’t the old USB keyboard that had a broken ctrl key, as I’m typing on a brand new one right now. Every now and again, the CTRL key will behave as if pressed, causing my scrolling to zoom in or out, activating commands like closing windows, saving files, and so on. Mayhem everywhere. I’ve actually tried unplugging all keyboards, including the laptop’s internal keyboard from the motherboard, and I’m still encountering this issue. Any advice?

I’m using Fedora 41 with the KDE spin.

4

You might try running the following command in your terminal and watching for a line that indicates the Ctrl key has been pressed.

sudo libinput debug-events

You should (eventually) see a line similar to the following.

-event5   KEYBOARD_KEY                +11.456s	KEY_RIGHTCTRL (97) pressed

The first column of the above output will indicate what device the key event came from. Then use the following command (substituting your event handler) and you should be able to find out where the key presses are coming from.

# udevadm info /dev/input/event5
P: /devices/pci0000:00/0000:00:14.0/usb1/1-11/1-11.3/1-11.3:1.0/0003:413C:2105.0003/input/input5/event5
M: event5
R: 5
U: input
D: c 13:69
N: input/event5
L: 0
S: input/by-id/usb-Dell_Dell_USB_Keyboard-event-kbd
S: input/by-path/pci-0000:00:14.0-usbv2-0:11.3:1.0-event-kbd
S: input/by-path/pci-0000:00:14.0-usb-0:11.3:1.0-event-kbd
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-11/1-11.3/1-11.3:1.0/0003:413C:2105.0003/input/input5/event5
E: DEVNAME=/dev/input/event5
E: MAJOR=13
E: MINOR=69
E: SUBSYSTEM=input
E: USEC_INITIALIZED=8395913
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_INPUT_KEYBOARD=1
E: ID_BUS=usb
E: ID_MODEL=Dell_USB_Keyboard
E: ID_MODEL_ENC=Dell\x20USB\x20Keyboard
E: ID_MODEL_ID=2105
E: ID_SERIAL=Dell_Dell_USB_Keyboard
E: ID_VENDOR=Dell
E: ID_VENDOR_ENC=Dell
E: ID_VENDOR_ID=413c
E: ID_REVISION=0352
E: ID_TYPE=hid
E: ID_USB_MODEL=Dell_USB_Keyboard
E: ID_USB_MODEL_ENC=Dell\x20USB\x20Keyboard
E: ID_USB_MODEL_ID=2105
E: ID_USB_SERIAL=Dell_Dell_USB_Keyboard
E: ID_USB_VENDOR=Dell
E: ID_USB_VENDOR_ENC=Dell
E: ID_USB_VENDOR_ID=413c
E: ID_USB_REVISION=0352
E: ID_USB_TYPE=hid
E: ID_USB_INTERFACES=:030101:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=usbhid
E: ID_PATH_WITH_USB_REVISION=pci-0000:00:14.0-usbv2-0:11.3:1.0
E: ID_PATH=pci-0000:00:14.0-usb-0:11.3:1.0
E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_11_3_1_0
E: LIBINPUT_DEVICE_GROUP=3/413c/2105:usb-0000:00:14.0-11
E: DEVLINKS=/dev/input/by-id/usb-Dell_Dell_USB_Keyboard-event-kbd /dev/input/by-path/pci-0000:00:14.0-usbv2-0:11.3:1.0-event-kbd /dev/input/by-path/pci-0000:00:14.0-usb-0:11.3:1.0-event-kbd
E: TAGS=:power-switch:
E: CURRENT_TAGS=:power-switch:
2 Likes
5

Okay, so I think I found it. It appears to be coming from my laptops internal keyboard, which I dug into to disconnect the ribbon from just the other day. I don’t understand how that can be.

event3 KEYBOARD_KEY +133.360s *** (-1) pressed
event3 KEYBOARD_KEY +134.927s *** (-1) released

glancing up, event 3 seems to be

-event3 DEVICE_ADDED AT Translated Set 2 keyboard seat0 default group7 cap:k

and the udevadm info returned

udevadm info /dev/input/event3
P: /devices/platform/i8042/serio0/input/input3/event3
M: event3
R: 3
U: input
D: c 13:67
N: input/event3
L: 0
S: input/by-path/platform-i8042-serio-0-event-kbd
E: DEVPATH=/devices/platform/i8042/serio0/input/input3/event3
E: DEVNAME=/dev/input/event3
E: MAJOR=13
E: MINOR=67
E: SUBSYSTEM=input
E: USEC_INITIALIZED=32583588
E: KEYBOARD_KEY_65=hangup_phone
E: KEYBOARD_KEY_66=pickup_phone
E: KEYBOARD_KEY_81=fn_esc
E: KEYBOARD_KEY_89=battery
E: KEYBOARD_KEY_8a=screenlock
E: KEYBOARD_KEY_8b=camera
E: KEYBOARD_KEY_8c=media
E: KEYBOARD_KEY_8e=dvd
E: KEYBOARD_KEY_92=brightnessdown
E: KEYBOARD_KEY_97=brightnessup
E: KEYBOARD_KEY_b1=help
E: KEYBOARD_KEY_b3=brightness_auto
E: KEYBOARD_KEY_d7=wlan
E: KEYBOARD_KEY_ee=switchvideomode
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_INPUT_KEYBOARD=1
E: ID_BUS=i8042
E: ID_SERIAL=noserial
E: ID_PATH=platform-i8042-serio-0
E: ID_PATH_TAG=platform-i8042-serio-0
E: LIBINPUT_DEVICE_GROUP=11/1/1:isa0060/serio0
E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-0-event-kbd
E: TAGS=:power-switch:
E: CURRENT_TAGS=:power-switch:

lines 1-40

6

You should be able to craft a udev rule to block an input device. I see someone did something similar here: Disabling device with udev - #2 by jawse

But you need to craft the rule so it specifically matches your device. I’m not sure what attributes in the output you provided would be unique and consistent.

There should be ID_VENDOR_ID and ID_MODEL_ID attributes as there were from my sample output, but yours is missing that. Maybe you can just match on ENV{ID_BUS}=="i8042". I don’t know if that would match too much or not.

The event number (event3 in your example) is likely to change between reboots, so you don’t want to key on (just) that.

3 Likes
7

I suspect that the hardware now has floating inputs that are not correctly terminated on the motherboard and are sensing random signals.
This is comon when a circuit is designed to have a terminating load, the keyboard in this case.

I’m guessing that the keyboard was failing which is why you unplugged it.

2 Likes
8

That’s right. I had a little workaround on windows where I’d just disable those keys, but I couldn’t grok how to do that here on fedora so I just unplugged the ribbon and got a usb keyboard.

9

I just tried this with no luck, but I’m unsure if I’ve even got the formatting right. First time doing anything with udev.

ACTION==“add|change”, KERNEL==“event[0-9]*”, ENV{ID_BUS}=="i8042", ENV{LIBINPUT_IGNORE_DEVICE}="1"
10

I think the text has been corrupted slightly somewhere along the line. Some of the double quotes appear to be encoded from the Unicode character set, but I expect the udev rule parser can only handle ASCII. Otherwise, it looks right to me.

1 Like
11

@penguinoccultist Did you happen to use a word process app while copying the text?
Word Processors like to “fix” your quotes, which breaks command line tools.

2 Likes
12

eeyup. If nothing else, I’m learning loads from this headache hehe. Fixed the quotes and rebooted, i’ve yet to see the problem resurface, but the morning is still young. I’ll report back after lunch if the rule works.

edit: actually no, I remembered the libinput debug-events command @glb offered earlier and just checked to see if the phantom keyboard was in the listed events. It’s gone now! Exorcism complete, I think I can safely mark this as solved. Thanks all!

1 Like