My keyboard has a mind of its own and it's driving me crazy. I'm convinced it's not *entirely* a hardware problem, hence this question. Computer is a low-end laptop, fairly recent model. A group of exactly 7 keys (9 0 o p l . UP_ARROW) will spontaneously stop responding for (seemingly) random periods. Sometimes I can wake them up by holding one down for a few seconds, at which point they all begin to function again. After "waking", the keys will often be hypersensitive (type "p" and get "ppp") or only function independently and not in combination (CTRL-p will be ignored). After one reboot the whole problem disappeared completely for two months. So it seems there's at least a software component to it - and therefore the potential for a workaround. An [almost identical issue](https://forum-en.msi.com/index.php?threads/the-keys-on-my-keyboard-randomly-stop-working-does-anyone-know-how-to-fix-this-issue.387039/) has been reported for MSI laptops. Replacing the keyboard would be either extremely tricky or very expensive. I've sometimes been resorting to a USB keyboard but it's a total PITA. Any ideas for workarounds if not a magic solution?

For around 2-3 weeks I have the problem with Fedora 42 on my Dell Precision 5530 that my Ctrl keystroke is not registered. I did not change recently any keyboard configuration. For example when I try to copy text by pressing Ctrl + C repeatedly in a text editor it replaced my text with ccccc. After several attempts it works. Same applies for undo Ctrl + Z or pasting Ctrl + v. I have this with any combinattion using the Ctrl button. The problem is that this happens randomly every hour or even more often with my built-in keyboard, with my external home keyboard and the bluetooth keyboard. This happens in X11 and in Wayland. My home keyboard is also connected via a KVM switch on my PC that is also running Fedora 42 and I don't have any problem there. I'm not sure if this problem also occurs with other keys Alt or Shift but I am using Ctrl heavely as a developer using IntelliJ. I have this problem in any application besides my IDE. I tried checking keyrelease registration on hardware level but it makes it very difficult since I can' t reproduce it on command. I used this command: xev | grep -i keyrelease -A5 Why does my Ctrl randomly not work? Fedora release 42 (Adams) NAME="Fedora Linux" VERSION="42 (Workstation Edition)" RELEASE_TYPE=stable ID=fedora VERSION_ID=42 VERSION_CODENAME="" PLATFORM_ID="platform:f42" PRETTY_NAME="Fedora Linux 42 (Workstation Edition)" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:42" DEFAULT_HOSTNAME="fedora" HOME_URL="https://fedoraproject.org/ " DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f42/system-administrators-guide/ " SUPPORT_URL="https://ask.fedoraproject.org/ " BUG_REPORT_URL="https://bugzilla.redhat.com/ " REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=42 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=42 SUPPORT_END=2026-05-13 VARIANT="Workstation Edition" VARIANT_ID=workstation Fedora release 42 (Adams) Fedora release 42 (Adams)

I am trying to run Ubuntu 18.04 on a laptop with an AMD A12 processor and Radeon R7 graphics. I am having nothing but problems and am very discouraged with Ubuntu though I used 12.04 for years without such problems. I have two problems that are maddening, and I will post them separately. The problems happen only on Gnome and Ubuntu on Xorg and do not happen on Wayland. However, I am told that it's best not to run Gnome on Wayland. This problem is that the computer sometimes doesn't wake up from suspend. Well, I think it does wake up because the optical drive spins and the hard drive ticks away, but I cannot login because the lock screen is a hash of colors or a distorted background without a place to login. I cannot even Ctrl-Alt-F1 to get to a prompt. All input is frozen. I am wondering if Xorg is configured correctly. I am running the Oilaf video driver which works well under Wayland so I don't know if there is a problem with Xorg and that driver.

Is there a command line (CLI) command to disable all keyboards on a machine, and then also a CLI command to re-enable them? I'm on a laptop with an internal and external keyboard, I need to disable/enable both of them. ## More Details I'm on Ubuntu 22.04.3 LTS. It should disable the keyboards across the board, it should not work anywhere at all (CLI, GUI, etc). I'm creating a bash script that disables all keyboards for a finite time, once the time is up the script re-enables the keyboards.

I noticed that there are KEY_KP{0-9} ten keycodes in the evtest output *"Supported events"* section, but I don't know what they are. I'm looking for a few keys to use for a particular keyboard(Chromebook function keys) and bind the function in the desktop environment. I've used the event's definitions (such as KEY_REFRESH) as much as I can, but some functions like *Fullscreen* and *Overview* aren't defined here. So now I'm going to use f{13-24} to implement them. although I'm still curious what's the KEY_KP is. By the way, I'm using [keyd](https://github.com/rvaiya/keyd) .

I'm writing a desktop automation software, which drives a GUI desktop, on linux. It works pretty well, but Wayland is blocking inter-window communication, especially when entering non-ASCII characters into text boxes. For comparison, on Windows, I used sendkeys API, and most programs obeyed. On X systems, there's pyautogui, xdotool, and other means, since there's no isolation between windows. The programming solutions I've tested to drive and simulate user input: 1. uinput (python-uinput) 2. pyAutoGui - 3. ydotool ignores non-ASCII (officially). It runs its own daemon though, so it's slower than any direct API or DBus option. 4. wtype doesn't run on KDE nor Gnome. 5. dotool doesn't work for emoji, garbles nonascii 6. kdotool can't type characters. There's a strict permissions issue with Wayland and how it (doesn't) permit(s) inter-window communication. But even when run as root, these tools don't allow non-ASCII characters. I know some ugly workarounds, but they all come with a price tag, such as using the clipboard, and triggering a Ctrl+V event. Any ideas how to send or emulate a keyboard event for unicode non-ASCII? (I'm using Arch-derivatives with KDE, but the same is applicable to Gnome, and maybe other desktop environments.)

When using RemotePC to remote-desktoping from Win 11 to Linux Ubuntu 22.04 over the web, the keyboard isn't working well, and, in particular, Ctrl-key commands and the like don't work. Despite being officially cross-platform, RemotePC doesn't seem to have a native feature to enable it for Win to Linux. Is there any simple solution that allows using the keyboard properly, incl. sending Ctrl-keys and the like? I've seen resembling questions answered for other RD software such as Remmina, but so far found no solution for RemotePC. I'd like to use RemotePC as it ticks off a few boxes in terms of simple setup & basic features that I've so far not seen all ticked by other RD software (unless some which are even much more expensive than RemotePC).

I set up an IR receiver with ir-keytable to be able to control some audio player from an remote. It works but I had to use some weird available key codes which were correctly caught by keyboard custom shortcuts. More specific: My OS is Linux Mint XFCE. I use an USB IR receiver AIM IR605Q setup with ir-keytable. I mapped "play key" from remote with "KEY_PLAYPAUSE" key code and it works immediately. I think audio player get this standard media play/pause event from OS. If I try to map "next song key" from remote with "KEY_NEXT" (or "KEY_NEXTSONG") it never works. KEY_NEXT event never fires anything. But when I launch ir-keytable tests, the key-up is seen and "KEY_NEXT" code is properly shown. By the way, my laptop keyboard has a media key "next song" which works as expected. My work-around is to use "KEY_CLOSE" for instance instead of KEY_NEXT (in remote config file read by ir-keytable), and then with a custom keyboard shortcut, I catch it and launch audio client with option --next. This is not amazing, but it works... I looked for hours without success to understand why I can't use right key codes (these codes are less than 8 bits...). (By the way, I first tried LIRC with no more success.)

I have 3 USB-keyboards attached to the Linux. Normally, when writing on any one, the characters "going" to the currently active application, e.g. to terminal or any other app. But, me reading the keyboard events from two keyboards directly by reading the particular /dev/input/eventX devices using some Perl module . While the script reads and decodes all events correctly, the entered keys are also going into the active application. The question is: It is possible to stop routing the keyboard events from particular keyboard to the active application? E.g. somewhat tell to kernel that inputs from a particular keyboard should not be taken as normal keyboard input. Because the X11 reads from every device which has device nodes in the /dev/input/event* it kooks like there are two possible solutions: 1. Somewhat change the name of the USB "keyboard" to another name instead of eventN, for example /dev/input/myinput0. Unfortunately, the udev rules doesn't allows renaming the device. (The NAME directive in the rules.d works only for network devices, for other devices could create only symlink) 2. Somewhat change the X11 configuration, in the /usr/share/X11/xorg.conf.d/10-evdev.conf, to ignore some particular "keyboard-like" devices - e.g. don't read every eventN device. Currently in my system it contains: Section "InputClass" Identifier "evdev keyboard catchall" MatchIsKeyboard "on" MatchDevicePath "/dev/input/event*" Driver "evdev" EndSection Do you have any idea how to do any of the above? The real background: I have attached two USB-RFID readers. They act as keyboards, e.g. when I touching the reader with the RFID-tag, it sends the RFID-number exactly as they was typed on the keyboard, e.g the readers act like a normal keyboard. My application could read the RFID events (in the background), and (of course) I don't want get the characters from RFID into the active window.

I suspect this can't be done, but I would like to disable a specific key (namely '6' on the top row) on a specific keyboard (namely my laptop internal keyboard). The key is spamming 6s but is otherwise working (and I've ordered a replacement but it will take a long time due to location). I am mostly using a USB keyboard but it is a pain to disable an entire keyboard (using xinput --float) just for one key. So: is it possible to disable a specific key on a specific keyboard? I am using Kubuntu 19.10 although I suspect that is not important for this.

I have a keyboard whose F2, F3, F4 keys send ctrl+a, ctrl+c, ctrl+v events respectively instead of a unique keycode which could be remapped easily using xmodmap keycode mapping. My goal is to use the keyboard's function keys as function keys instead of media keys, without having to press the keyboard's Fn modifier. The keyboard doesn't appear to support a built-in FN-switch to send FN keys by default. How can I achieve this mapping? Looking at the xev logs, the events appear indistinguishable: Real ctrl+a keypress:

KeyPress event, serial 33, synthetic NO, window 0x2a00001,
    root 0x79a, subw 0x0, time 59266583, (648,900), root:(648,900),
    state 0x0, keycode 66 (keysym 0xffe3, Control_L), same_screen YES,
    XKeysymToKeycode returns keycode: 37
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x2a00001,
    root 0x79a, subw 0x0, time 59266869, (647,899), root:(648,900),
    state 0x4, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (01) ""
    XmbLookupString gives 1 bytes: (01) ""
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x2a00001,
    root 0x79a, subw 0x0, time 59266989, (647,899), root:(648,900),
    state 0x4, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (01) ""
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x2a00001,
    root 0x79a, subw 0x0, time 59266989, (647,899), root:(648,900),
    state 0x4, keycode 66 (keysym 0xffe3, Control_L), same_screen YES,
    XKeysymToKeycode returns keycode: 37
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Pressing the F2 key:

KeyPress event, serial 33, synthetic NO, window 0x2a00001,
    root 0x79a, subw 0x0, time 59337346, (648,900), root:(648,900),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x2a00001,
    root 0x79a, subw 0x0, time 59337346, (648,900), root:(648,900),
    state 0x4, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (01) ""
    XmbLookupString gives 1 bytes: (01) ""
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x2a00001,
    root 0x79a, subw 0x0, time 59337451, (648,900), root:(648,900),
    state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x2a00001,
    root 0x79a, subw 0x0, time 59337451, (648,900), root:(648,900),
    state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (61) "a"
    XFilterEvent returns: False

The keyboard's brand is listed as EOENKK. Output of bluetoothctl info :

[Bluetooth Keyboard]# info 15:10:40:4F:00:07
Device 15:10:40:4F:00:07 (public)
        Name: Bluetooth Keyboard
        Alias: Bluetooth Keyboard
        Appearance: 0x03c1
        Icon: input-keyboard
        Paired: yes
        Bonded: yes
        Trusted: no
        Blocked: no
        Connected: yes
        WakeAllowed: yes
        LegacyPairing: no
        UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
        UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
        UUID: Human Interface Device    (00001812-0000-1000-8000-00805f9b34fb)
        UUID: Unknown                   (0000ff50-0000-1000-8000-00805f9b34fb)
        Modalias: usb:v04E8p7021d0300
        ManufacturerData Key: 0x4b51
        ManufacturerData Value:
  49 45                                            IE              
[Bluetooth Keyboard]#

A picture of the keyboard:

Is there a way to programmatically read, detect or get notified about the **actual physical state** of a modifier key, **without requiring root level access** rights? I tried X11, XCB and XKB, but their event driven approach only registers modifier changes after the modifier key either has been released physically or been otherwise used (e.g. during mouse click). I'm looking for a way to asynchronously be able to read out e.g. the SHIFT key pressed/released state, without having to wait for a "consuming" next event to happen. If X11/XCB/XKB does not allow this, I would also consider going into the HID direction, but before doing this, I wanted to clarify, if I didn't overlook something simple like a non-blocking modifier event mode or something similar which just simply needs to be switched on. **EDIT (2023-09-30)**: I now also took a look at XInput v2 and its raw key input support, but it did not help much. The event processing apparently already inherits this behaviour from driver level. The next step was to investigate the output from evtest, and this seems to confirm the theory, that it is not even possible to asynchronously see the physical state, if the driver layer does not process/communicate the related state change synchronously. This is a copy from the terminal output, where you can see that the modifier press/release is just some milliseconds apart, while actually they we re pressed for longer than that: Testing ... (interrupt to exit) Event: time 1696090563.122466, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1c Event: time 1696090563.122466, type 1 (EV_KEY), code 28 (KEY_ENTER), value 0 Event: time 1696090563.122466, -------------- SYN_REPORT ------------ Event: time 1696090567.475603, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a Event: time 1696090567.475603, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 1 Event: time 1696090567.475603, -------------- SYN_REPORT ------------ Event: time 1696090567.487761, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a Event: time 1696090567.487761, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 0 Event: time 1696090567.487761, -------------- SYN_REPORT ------------ Event: time 1696090570.051134, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a Event: time 1696090570.051134, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 1 Event: time 1696090570.051134, -------------- SYN_REPORT ------------ Event: time 1696090570.062911, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a Event: time 1696090570.062911, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 0 Event: time 1696090570.062911, -------------- SYN_REPORT ------------ Event: time 1696090574.108130, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a Event: time 1696090574.108130, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 1 Event: time 1696090574.108130, -------------- SYN_REPORT ------------ Event: time 1696090574.119016, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a Event: time 1696090574.119016, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 0 Event: time 1696090574.119016, -------------- SYN_REPORT ------------ Event: time 1696090576.276169, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1d Event: time 1696090576.276169, type 1 (EV_KEY), code 29 (KEY_LEFTCTRL), value 1 Event: time 1696090576.276169, -------------- SYN_REPORT ------------ Event: time 1696090576.288810, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1d Event: time 1696090576.288810, type 1 (EV_KEY), code 29 (KEY_LEFTCTRL), value 0 Event: time 1696090576.288810, -------------- SYN_REPORT ------------ Event: time 1696090577.396269, type 4 (EV_MSC), code 4 (MSC_SCAN), value 38 Event: time 1696090577.396269, type 1 (EV_KEY), code 56 (KEY_LEFTALT), value 1 Event: time 1696090577.396269, -------------- SYN_REPORT ------------ Event: time 1696090577.407817, type 4 (EV_MSC), code 4 (MSC_SCAN), value 38 Event: time 1696090577.407817, type 1 (EV_KEY), code 56 (KEY_LEFTALT), value 0 Event: time 1696090577.407817, -------------- SYN_REPORT ------------

After one or two minutes, the first key I press is ignored. Which key doesn’t matter, Meta, Alt, Space, Shift, numbers, letters. It is as if the keyboard goes on a dormant mode after about 90 seconds or so, then the first key pressed wakes it up. Why? I can’t find anything addressing this, and it seems somewhat unbelievable. I have been running Manjaro Gnome for the last several months, reinstalled, swapped keyboards with other machines, installed the same USB installer on other machines without duplicating the problem, enabled and disabled Wayland running X11, and the problem persists on this one machine with Linux. I'm dual-booting to Windows 10 on the same machine with OEM registered Windows license keys and Windows has no problem like this at all. I’m running Gnome 44.1 Linux 6.1.31-2-MANJARO with X11 on a 4th gen i7-4790 x8, ASUS board "All Series" Firmware 0603, and AMD Radeon™ RX 470 GPU, with 16 GB of RAM. But, I don’t know where to look or how to check to see what is causing this. My only guesses are: Arch, Gnome, Xorg. Where do I look? How do I fix?

I've had to leave xim behind because of various graphical issues. And I'm trying to set up ibus but having trouble getting it to cycle through keyboards. Other info: - Debian Testing - Awesome WM --- This was my set up with before using ibus. I mapped one of my special keys on my keyboard to ISO_Next_Group. With the set up below I could cycle through the three keyboad layouts using my special key and compose using PrtSc. ### ~/.sessionrc

setxkbmap -layout 'us,gr,il' -variant ',polytonic,biblical' -option ctrl:nocaps,compose:prsc
xmodmap ~/.Xmodmap
export GTK_IM_MODULE=xim

### ~/.Xmodmap

keycode 147 = ISO_Next_Group NoSymbol

xev gives this when I press my key (both events occur on keydown and nothing on keyup):

KeyPress event, serial 36, synthetic NO, window 0x3200001,
    root 0x79b, subw 0x0, time 9147156, (-108,258), root:(763,709),
    state 0x0, keycode 147 (keysym 0xfe08, ISO_Next_Group), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x3200001,
    root 0x79b, subw 0x0, time 9147156, (-108,258), root:(763,709),
    state 0x0, keycode 147 (keysym 0xfe08, ISO_Next_Group), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

--- With ibus, my ~/.Xmodmap is the same and ~/.xsessionrc now contains:

setxkbmap -layout 'us,gr,il' -variant ',polytonic,biblical' -option ctrl:nocaps,compose:prsc
xmodmap ~/.Xmodmap
export GTK_IM_MODULE=ibus
export QT_IM_MODULE=ibus
export XMODIFIERS=@im=ibus
ibus-daemon -rx &

In ibus-setup, all three keyboard layouts are listed and the key to change layouts is ISO_Next_group, but when I press this key, rather than cycling through all three layouts, ibus just toggles between us and the most recently selected (by mouse) other layout. Once ibus-daemon is loaded, I notice that the output from xev also changes when I press my ISO_Next_Group key:

FocusOut event, serial 33, synthetic NO, window 0x4e00001,
    mode NotifyGrab, detail NotifyAncestor

FocusOut event, serial 33, synthetic NO, window 0x4e00001,
    mode NotifyUngrab, detail NotifyPointer

FocusIn event, serial 33, synthetic NO, window 0x4e00001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 33, synthetic NO, window 0x0,
    keys:  2   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

--- **How do I get ibus to cycle through all three keyboard layouts?** --- ### Update I switched around the hotkeys: - + ISO_Next_Group → switch layout - ISO_Next_Group → Enter emoji This mostly seems to work. I had to add GLFW_IM_MODULE=ibus for kitty support.

**OP entirely re-edited.** My Razer Cynosa chroma is one physical device (basically no more than a PC_105 keyboard) offering the particularity to offer 3 interfaces (1) one of them for simultaneously sending some scancode and another for sending some internally transcoded mouse report when whatever key is depressed. I am looking for a way to use the latter as a mouse under X. ---------- All the 3 interfaces are correctly enumerated at boot time and bound to the appropriate hid-generic in-kernel built driver (2) Then rebound to the razerkbd driver at modeprobe time (3) Each one of these being later on associated to input events and registered by the X11 server (xorg-server-21.1.4) : - In an usual way for such devices regarding the first interface of keyboard type (device id 9) and the third of mouse type (device id 11) (4) - In some unusual to me and at least ambiguous way for the second of keyboard type (device id 10). (5) (Cf. the Configuring as mouse / Configuring as keyboard sequence) All this leading to confusing reports $ xinput --list --short ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ MOSART Semi. 2.4G Wireless Mouse id=8 [slave pointer (2)] ⎜ ↳ Razer Razer Cynosa Chroma id=10 [slave pointer (2)] ⎜ ↳ Razer Razer Cynosa Chroma id=11 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Power Button id=7 [slave keyboard (3)] ↳ Razer Razer Cynosa Chroma id=9 [slave keyboard (3)] (device id 10 reported only as slave pointer whereas initially registered of KEYBOARD type.) Having noticed that cat /dev/input/event5 printouts mouslike communication when depressing any key and since event5 is linked to device id 10, xinput --test-xi2 10 only logs keyboard events type 13 (*RawKeyPress*) and 14 (*RawKeyRelease*) Would evdev be somehow confused ? ---------- **1 : lsusb -vs 008:002 report :** $ lsusb -vs 008:002 Bus 008 Device 002: ID 1532:022a Razer USA, Ltd Cynosa Chroma Device Descriptor: … Configuration Descriptor: … bNumInterfaces 3 … Interface Descriptor: … bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard … Interface Descriptor: … bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 1 Keyboard … Interface Descriptor: … bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 2 Mouse … ---------- **2 : Bootlog enumeration of usb devices** [kernel] input: Razer Razer Cynosa Chroma as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.0/0003:1532:022A.0002/input/input4 [kernel] hid-generic 0003:1532:022A.0002: input: USB HID v1.11 Keyboard [Razer Razer Cynosa Chroma] on usb-0000:00:1d.2-2/input0 [kernel] input: Razer Razer Cynosa Chroma Keyboard as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.1/0003:1532:022A.0003/input/input5 [kernel] input: Razer Razer Cynosa Chroma Consumer Control as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.1/0003:1532:022A.0003/input/input6 [kernel] hid-generic 0003:1532:022A.0003: input: USB HID v1.11 Keyboard [Razer Razer Cynosa Chroma] on usb-0000:00:1d.2-2/input1 [kernel] input: Razer Razer Cynosa Chroma as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.2/0003:1532:022A.0004/input/input9 [kernel] hid-generic 0003:1532:022A.0004: input: USB HID v1.11 Mouse [Razer Razer Cynosa Chroma] on usb-0000:00:1d.2-2/input2 ---------- **3 : Rebinding of Razer interfaces at modprobe time** [kernel] input: Razer Razer Cynosa Chroma as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.0/0003:1532:022A.0002/input/input10 [kernel] razerkbd 0003:1532:022A.0002: input: USB HID v1.11 Keyboard [Razer Razer Cynosa Chroma] on usb-0000:00:1d.2-2/input0 [kernel] input: Razer Razer Cynosa Chroma as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.1/0003:1532:022A.0003/input/input11 [kernel] razerkbd 0003:1532:022A.0003: input: USB HID v1.11 Keyboard [Razer Razer Cynosa Chroma] on usb-0000:00:1d.2-2/input1 [kernel] input: Razer Razer Cynosa Chroma as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.2/0003:1532:022A.0004/input/input12 [kernel] razerkbd 0003:1532:022A.0004: input: USB HID v1.11 Mouse [Razer Razer Cynosa Chroma] on usb-0000:00:1d.2-2/input2 ---------- **4 : XCONFIG-ing of first keyboard interface and mouse interface** config/udev: Adding input device Razer Razer Cynosa Chroma (/dev/input/event4) Razer Razer Cynosa Chroma: Applying InputClass "evdev keyboard catchall" Razer Razer Cynosa Chroma: Applying InputClass "system-keyboard" Using input driver 'evdev' for 'Razer Razer Cynosa Chroma' systemd-logind: got fd for /dev/input/event4 13:68 fd 39 paused 0 Razer Razer Cynosa Chroma: always reports core events evdev: Razer Razer Cynosa Chroma: Device: "/dev/input/event4" evdev: Razer Razer Cynosa Chroma: Vendor 0x1532 Product 0x22a evdev: Razer Razer Cynosa Chroma: Found keys evdev: Razer Razer Cynosa Chroma: Configuring as keyboard Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.0/0003:1532:022A.0002/input/input10/event4" Adding extended input device "Razer Razer Cynosa Chroma" (type: KEYBOARD, id 9) Option "xkb_rules" "evdev" config/udev: Adding input device Razer Razer Cynosa Chroma (/dev/input/event6) Razer Razer Cynosa Chroma: Applying InputClass "evdev pointer catchall" Using input driver 'evdev' for 'Razer Razer Cynosa Chroma' systemd-logind: got fd for /dev/input/event6 13:70 fd 41 paused 0 Razer Razer Cynosa Chroma: always reports core events evdev: Razer Razer Cynosa Chroma: Device: "/dev/input/event6" evdev: Razer Razer Cynosa Chroma: Vendor 0x1532 Product 0x22a evdev: Razer Razer Cynosa Chroma: Found 9 mouse buttons evdev: Razer Razer Cynosa Chroma: Found scroll wheel(s) evdev: Razer Razer Cynosa Chroma: Found relative axes evdev: Razer Razer Cynosa Chroma: Found x and y relative axes evdev: Razer Razer Cynosa Chroma: Configuring as mouse evdev: Razer Razer Cynosa Chroma: Adding scrollwheel support evdev: Razer Razer Cynosa Chroma: YAxisMapping: buttons 4 and 5 evdev: Razer Razer Cynosa Chroma: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.2/0003:1532:022A.0004/input/input12/event6" XINPUT: Adding extended input device "Razer Razer Cynosa Chroma" (type: MOUSE, id 11) evdev: Razer Razer Cynosa Chroma: initialized for relative axes. Razer Razer Cynosa Chroma: (accel) keeping acceleration scheme 1 Razer Razer Cynosa Chroma: (accel) acceleration profile 0 Razer Razer Cynosa Chroma: (accel) acceleration factor: 2.000 Razer Razer Cynosa Chroma: (accel) acceleration threshold: 4 ---------- **5 : Ambiguous XCONFIG-ing of second keyboard interface** config/udev: Adding input device Razer Razer Cynosa Chroma (/dev/input/event5) Razer Razer Cynosa Chroma: Applying InputClass "evdev keyboard catchall" Razer Razer Cynosa Chroma: Applying InputClass "system-keyboard" Using input driver 'evdev' for 'Razer Razer Cynosa Chroma' systemd-logind: got fd for /dev/input/event5 13:69 fd 40 paused 0 Razer Razer Cynosa Chroma: always reports core events evdev: Razer Razer Cynosa Chroma: Device: "/dev/input/event5" evdev: Razer Razer Cynosa Chroma: Vendor 0x1532 Product 0x22a evdev: Razer Razer Cynosa Chroma: Found 1 mouse buttons evdev: Razer Razer Cynosa Chroma: Found scroll wheel(s) evdev: Razer Razer Cynosa Chroma: Found relative axes evdev: Razer Razer Cynosa Chroma: Forcing relative x/y axes to exist. evdev: Razer Razer Cynosa Chroma: Found absolute axes evdev: Razer Razer Cynosa Chroma: Forcing absolute x/y axes to exist. evdev: Razer Razer Cynosa Chroma: Found keys evdev: Razer Razer Cynosa Chroma: Configuring as mouse evdev: Razer Razer Cynosa Chroma: Configuring as keyboard evdev: Razer Razer Cynosa Chroma: Adding scrollwheel support evdev: Razer Razer Cynosa Chroma: YAxisMapping: buttons 4 and 5 evdev: Razer Razer Cynosa Chroma: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.1/0003:1532:022A.0003/input/input11/event5" XINPUT: Adding extended input device "Razer Razer Cynosa Chroma" (type: KEYBOARD, id 10) Option "xkb_rules" "evdev" evdev: Razer Razer Cynosa Chroma: initialized for relative axes. evdev: Razer Razer Cynosa Chroma: ignoring absolute axes. Razer Razer Cynosa Chroma: (accel) keeping acceleration scheme 1 Razer Razer Cynosa Chroma: (accel) acceleration profile 0 Razer Razer Cynosa Chroma: (accel) acceleration factor: 2.000 Razer Razer Cynosa Chroma: (accel) acceleration threshold: 4

My browser (chrome but I think it doesn't matter) receives events for keystrokes which are not intended for it. For example, I'm doing alt+tab in Mate and then I press escape (while still holding the alt). This has the intended effect of the alt+tab dialog disappearing without switching the window but also the unintended effect of the browser thinking I just pressed escape (which affects the web application I'm using). Looking for related questions I found this: https://unix.stackexchange.com/questions/36281/how-do-i-prevent-programs-from-sniffing-keystrokes-to-su-gksu but my case is a little different - I (kind of) trust the browser, I just don't want it to think that I've pressed a key. Is this something I can configure in xorg or in mate?

Today I had to restart my computer after a total freeze of Linux. After that I now have the problem that **KeepassXC 2.7.1 leads to a immediate logout of my Linux system as soon as I try to use the auto-type functionality**. It doesn't matter if it should type a user name, a password or both. I also tried different credentials - the problem stays the same.
In the weeks before I never had this problem, using this function very often.
=> __What could be the root cause for that problem?__

- Another odd thing is that KeePass asks now for a confirmation if it should auto-type into the window which was active before. It never posed this question before. I know this is a setting but I never changed this setting. - A second restart of Linux didn't solve this problem. After the restart I get the information that there is no space on partition /boot. But there are 82MB free space on this partition.

I have an usb keyboard connected to a linux box. I need to capture all keys that have been pressed and released. My keyboard n-key rollover meaning that it doesn't have limits on number of concurrent keys being held. They are all detected and reported. They keyboard works fine in terminal and x-windows. I can press and hold keys one after another and each time a new character appears on the screen. I tried ten and they are all detected. HOWEVER: when I read data from /dev/input/eventX corresponding to keyboard the data stops coming after 6 keys has been pressed. I wrote a small program in node.js, but I can observe the same behaviour even by doing "cat /dev/input/eventX". It's very puzzling, because I would assume that there is a same driver that is used to read keycodes and display them in terminal. Anyone has any idea where and why event file is not receiving any data past 6 keys? What would be a way around this problem ? Tried with RPI (Debian and Ubuntu), OrangePI (Ubuntu) and PC (LinuxMint). Thanks, M here is the node.js code * const InputEvent = require('input-event'); const input = new InputEvent('/dev/input/event0'); function keyReleased(input) { console.log(input.code); } const keyboard = new InputEvent.Keyboard(input); keyboard.on('data' , function(input) { console.log("DATA:" + input.code); }); *

I have a faulty keyboard that will fire additional keys when i press a single key. for example, when i click letter "D" on keyboard it will send "D5" $xev -event keyboard KeyPress event, serial 28, synthetic NO, window 0x3c00001, root 0x929, subw 0x0, time 7185644, (351,334), root:(2087,693), state 0x10, keycode 40 (keysym 0x64, d), same_screen YES, XLookupString gives 1 bytes: (64) "d" XmbLookupString gives 1 bytes: (64) "d" XFilterEvent returns: False KeyPress event, serial 28, synthetic NO, window 0x3c00001, root 0x929, subw 0x0, time 7185644, (351,334), root:(2087,693), state 0x10, keycode 84 (keysym 0xffb5, KP_5), same_screen YES, XLookupString gives 1 bytes: (35) "5" XmbLookupString gives 1 bytes: (35) "5" XFilterEvent returns: False KeyRelease event, serial 28, synthetic NO, window 0x3c00001, root 0x929, subw 0x0, time 7185716, (351,334), root:(2087,693), state 0x10, keycode 40 (keysym 0x64, d), same_screen YES, XLookupString gives 1 bytes: (64) "d" XFilterEvent returns: False KeyRelease event, serial 28, synthetic NO, window 0x3c00001, root 0x929, subw 0x0, time 7185716, (351,334), root:(2087,693), state 0x10, keycode 84 (keysym 0xffb5, KP_5), same_screen YES, XLookupString gives 1 bytes: (35) "5" XFilterEvent returns: False notice that both keypress events have the same timestamp. my question is, is there a way to block the second keyPress event if it has the same timestamp as the previous keyPress event? or is there any other way to block this second input?

My program uses the X11 key names like exclam and XF86Forward but internally uses the Linux keycodes found in /usr/include/linux/input-event-codes.h. It's just an awk program, and I've written an associative array with the most important keys (K["F1"] = 59) to start with, but I was wondering if I could generate it from somewhere. I found /usr/share/X11/xkb/keycodes/ but my greps didn't seem promising.