Debian 12, MATE.
Having a really strange apparently input issue that is rendering my system 100% unusable.
The initial symptoms manifested as: Suddenly a ton of pop ups and random menus opened while trying to type. In firefox, I pressed the letter h by itself, which opened the help menu, so it appeared that the alt key was stuck.
I then opened xev to try and run some tests. I then saw this:
thousands of times, constantly flooding in, over and over. I unplugged my keyboard, mouse, disconnected my bluetooth headset and disabled bluetooth, and the events kept coming.
It's 100% not the keyboard. I tried 4 different keyboards and tried it unplugged entirely and kept seeing the same issue, thousands of press and release events.
Nothing mentioning the alt key in xev, but then again, the output is basically useless as it's flooded by the key 204 events. Having a GUI that shows each key and the current press state would be nice for debugging problems like this.
A few more clues:
Here is the output fromA few questions to start with:
Having a really strange apparently input issue that is rendering my system 100% unusable.
The initial symptoms manifested as: Suddenly a ton of pop ups and random menus opened while trying to type. In firefox, I pressed the letter h by itself, which opened the help menu, so it appeared that the alt key was stuck.
I then opened xev to try and run some tests. I then saw this:
Code:
KeyPress event, serial 54, synthetic NO, window 0xca00001, root 0x421, subw 0x0, time 1421331971, (-1246,908), root:(1255,1254), state 0x0, keycode 204 (keysym 0x0, NoSymbol), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 54, synthetic NO, window 0xca00001, root 0x421, subw 0x0, time 1421332005, (-1246,908), root:(1255,1254), state 0x0, keycode 204 (keysym 0x0, NoSymbol), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False It's 100% not the keyboard. I tried 4 different keyboards and tried it unplugged entirely and kept seeing the same issue, thousands of press and release events.
Nothing mentioning the alt key in xev, but then again, the output is basically useless as it's flooded by the key 204 events. Having a GUI that shows each key and the current press state would be nice for debugging problems like this.
A few more clues:
- When the "alt key" issue occurs, the cursor flickers or disappears. I'm assuming that there are so many random keypresses that xorg can't even render the cursor. I also can't change window focus.
- If I'm getting the flood of events in xev, I can press any letter on the keyboard and the events will stop. I will wait a few minutes, doing nothing, the events will remain stopped, but as soon as I move the mouse or apparently as soon as I try to do something productive, I will start seeing the flood of 204 key press / release events again.
- On a whim, I tried doing: and I started to get the same flood of messages, both the key up and key down, but for keycode 100 now. So it seems like.....something is triggering xdotool keydown 204, and any time xdotool is invoked it gets stuck in this "rapid toggle" state?
Code:
xdotool keydown 100
Here is the output from
Code:
xinput --listCode:
⎡ Virtual core pointer id=2 [master pointer (3)]⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]⎜ ↳ Logitech G903 id=11 [slave pointer (2)]⎜ ↳ Keychron K8 Keychron K8 id=8 [slave pointer (2)]⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Keychron K8 Keychron K8 id=9 [slave keyboard (3)] ↳ Keychron K8 Keychron K8 id=10 [slave keyboard (3)] ↳ Logitech G903 id=12 [slave keyboard (3)] ↳ Logitech Candy id=13 [slave keyboard (3)] ↳ Power Button id=7 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)- Why is there a power button listed as a keyboard device? Twice in fact? Why is my keyboard listed under the pointer? Why is the mouse listed under the keyboard? What is the XTEST keyboard and why can't I disable it? Why is my keyboard listed twice in the keyboard section?
- If xev is showing "synthetic NO" is that 100% guaranteed proof that the key press is hardware and not software? Can this be spoofed? When I ran xdotool to test I was surprised to see "synthetic NO", shouldn't it be "synthetic YES" for that test?
- Is there any way to tell Linux "lock down my system so that that ONLY thing that can send a keypress is my physical keyboard" ?
- Is there any sort of graphical program that will *actually* show what keys are detected as being pressed? I tried key-mon, but it didn't show the alt key as being held down when I ran into the "alt key issue" as stated above.
- What exactly is going on here? How do I fix this?
Statistics: Posted by kerryhall — 2024-12-11 09:40 — Replies 1 — Views 51