[Software] Bizarre input issue

[kerryhall]

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:

Code: Select all

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   

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:

• 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:

  Code: Select all

  xdotool keydown 100

  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?

I have also tried rebooting, but still running into the same issue as soon as I try and use my system.

Here is the output from

Code: Select all

 xinput --list

Code: Select all

⎡ 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)

A few questions to start with:

• 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?

[arzgi]

Have you installed the right language pack to firefox, and same language in th firefox settings?

Code: Select all

arto@dell:~$ aptitude search firefox
p   activity-aware-firefox                      - wrapper to make Firefox aware of Plasma Desktop activ
i   firefox-esr                                 - Mozilla Firefox web browser - Extended Support Releas
p   firefox-esr-l10n-ach                        - Acoli language package for Firefox ESR               
p   firefox-esr-l10n-af                         - Afrikaans language package for Firefox ESR           
p   firefox-esr-l10n-all                        - All language packages for Firefox ESR (meta)         
p   firefox-esr-l10n-an                         - Aragonese language package for Firefox ESR           
p   firefox-esr-l10n-ar                         - Arabic language package for Firefox ESR              
p   firefox-esr-l10n-ast                        - Asturian language package for Firefox ESR            
p   firefox-esr-l10n-az                         - Azerbaijani language package for Firefox ESR         
p   firefox-esr-l10n-be                         - Belarusian language package for Firefox ESR          
p   firefox-esr-l10n-bg                         - Bulgarian language package for Firefox ESR           

And check alse /etc/default/keboard

Code: Select all

arto@dell:~$ cat /etc/default/keyboard 
# KEYBOARD CONFIGURATION FILE

# Consult the keyboard(5) manual page.

XKBMODEL="pc105"
XKBLAYOUT="fi"
XKBVARIANT=""
XKBOPTIONS="compose:menu,ctrl:nocaps"

BACKSPACE="guess"

[Aki]

Hello,

When does it happen ? Always? Sometimes?

Does it happen when in a virtual console (text console) ? You can activate it booting in single user mode from grub.

Does the keyboard work correctly with grub ?

Hope this helps

[Meow]

Please first do a very simple test:

When you start up the system, in the graphic login manager screen there is a toggle button in the lower left.
It toggles between Wayland (default) and X Window.

As Wayland is very instable, buggy, even flawed irreparably from scratch, the simplest method to rule out a Wayland problem always is to switch to X Window if any strangenesses or instabilities show up.

Rarely only such issues persist after having switched to X Window.
A big issue in this regard is that you must also make sure that libinput (Wayland's alternative to evdev etc) is not being used, because among many other things it breaks xinput (making it partially dysfunctional).

So the easiest way to avoid annoyances with Debian is to always first make sure that you remove, or at least deactivate Wayland from the system.

[kerryhall]

Have you installed the right language pack to firefox, and same language in th firefox settings?

I just used firefox as an example of a program indicating the symptoms of the alt key being held down.

Another one is if I press "ctrl + c", the copyq menu will pop up, which I have bound to "ctrl + alt + c".

[kerryhall]

Hello,

When does it happen ? Always? Sometimes?

Does it happen when in a virtual console (text console) ? You can activate it booting in single user mode from grub.

Does the keyboard work correctly with grub ?

Hope this helps

The "stuck alt key" issue seems to occur once every 5 minutes, seemingly randomly. The "thousands of 204 events" issue is constant.

How would I go about checking key events in a virtual console? I'm assuming I wouldn't be able to use xev for that.

Here is really what I need in order to start debugging this. I need a program that runs in a command line, that shows a 16 x 16 ncurses style grid of all 256 keycodes.

If at any time a key is pressed down, no matter what window has focus, that grid will indicate which key is being pressed *and which physical device is triggering it*. If it's a process sending a virtual keystroke, the name of the process should be indicated.

[kerryhall]

Is it possible for a disconnected keyboard to still be sending keypresses? Let's say there is some error in the keyboard and it tries to send 100k key press and release events. I can see those coming through in xev, but if I disconnect the keyboard, I would expect them to stop immediately if the physical keyboard is at fault. However, I don't know if there is some kind of buffer that could still be processing that potentially huge amount of data.

[kerryhall]

Keyboard seems to work fine in grub, although the keyboard input is pretty laggy, I don't know if that's normal for grub.

[kerryhall]

When you start up the system, in the graphic login manager screen there is a toggle button in the lower left.
It toggles between Wayland (default) and X Window.

I've only ever used xorg, confirmed with $XDG_SESSION_TYPE.

[kerryhall]

Well I seem to have found a way to get close to what I'm looking for here.

Code: Select all

xinput list

to show all the input devices

Code: Select all

xinput --list-props <id>

to get the /dev/input/eventX number

Then monitor the input device with:

Code: Select all

sudo evtest /dev/input/eventX

for example

Code: Select all

sudo evtest /dev/input/event5

[Meow]

Keyboard seems to work fine in grub, although the keyboard input is pretty laggy, I don't know if that's normal for grub.

At least this lagginess indicates that there is some problem, quite "low-level".
Such like mundane dirt, as I had several times?
I guess you already checked out different make/model keyboards to rule out a specific keyboard's problem?

[kerryhall]

At least this lagginess indicates that there is some problem, quite "low-level".
Such like mundane dirt, as I had several times?
I guess you already checked out different make/model keyboards to rule out a specific keyboard's problem?

I tried three different keyboards in grub, and each has the exact same lag.

There is no such lag in xorg.

[Meow]

Good, then it seems not be caused by a bad keyboard.
What mobo is this?
Do you have Legacy USB enable (or similar) on?
This makes the BIOS try emulating a PS/2 keyboard, often leading to strange problems similar to yours.