You are not logged in.
I recently bought a Cherry MX Board 3.0 S mechanical keyboard. It features RGB backlight, which unfortunately can only be configured using Cherry's proprietary Windows application - that is, until https://openrgb.org/ has implemented support for it. As the default color scheme is unbearable, I attached the keyboard to a windows notebook, used the Cherry software to change the color setting to something decent, installed the latest firmware (version 0126) along the way, and was ready to get started using it with Linux.
However, I quickly was disappointed, as my system, an up-to-date Arch installation on a Lenovo Thinkpad, behaved really weird as soon as the new keyboard was attached. I wasn't able to type in my password, couldn't press Ctrl-C in the terminal, the terminal's cursor was gone, the mouse cursor disappeared randomly, etc. I was puzzled for a day or two, until I started to debug the issue.
I found out that the keyboard does not show up as 1 USB device, but instead of 4, as xinput list shows:
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ CHERRY Mechanical Keyboard id=15 [slave pointer (2)]
⎜ ↳ CHERRY Mechanical Keyboard Mouse id=18 [slave pointer (2)]
...
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ CHERRY Mechanical Keyboard id=16 [slave keyboard (3)]
↳ CHERRY Mechanical Keyboard id=17 [slave keyboard (3)]
...Also, it registers 4 devices below /dev/input/event*. WTF is going on here?
When using xev, you can immediately see the root cause for the system's strange behaviour: one of these 4 USB devices sends 25 keypresses per second, like these:
KeyPress event, serial 31, synthetic NO, window 0x3000001,
root 0x1d6, subw 0x0, time 2325935, (440,577), root:(1404,601),
state 0x0, keycode 248 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 34, synthetic NO, window 0x3000001,
root 0x1d6, subw 0x0, time 2326597, (440,577), root:(1404,601),
state 0x0, keycode 248 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: FalseAt first, I wasn't sure whether this was an issue with some X component, but it must be directly related to the Linux kernel, as the issue is already apparent in the initrd, where it's impossible to type in the correct password to decrypt the root filesystem, as can be seen in this video:
https://youtu.be/_ulfZgKdzBw
Luckily, the keypresses come from one of the USB devices that don't seem to have any valid reason to exist, so once the problem is understood, it can be easily circumvented by disabling this device using an evdev rule, e.g. /etc/udev/rules.d/cherry-keyboard.rules:
ACTION=="add", SUBSYSTEM=="input", ATTRS{idVendor}=="046a", ATTRS{idProduct}=="0079", ATTR{capabilities/ev}=="10001f", ATTR{inhibited}="1"When adding this file to the initrd, entering the password for decrypting the root filesystem also becomes possible again. Then can be accomplished by adding this line to /etc/mkinitcpio.conf:
FILES=( /etc/udev/rules.d/cherry-keyboard.rules )With these modifications in place, the keyboard is fully usable. So here's my question: Where should I go to with this "solution"? Should this be part of the official udev database, and do I need to create a ticket in the systemd bug tracker? Or is this something that needs to be handled in the kernel, and should thus go to kernel's bugzilla? Or should I follow the advice shown there and create a ticket in the Arch bugtracker instead? Or somewhere else entirely? I'm a bit lost here, and I'd love to get this issue fixed so that future users don't have to go through all that debugging that I had to...
Thanks for any suggestions!
Offline
Same here and it can cause a lot of unexpected behavior, see e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1717426. But to implement a udev rule shouldn't be the right way to fix that issue. Instead i called the Cherry support and they already have an experimental, unofficial firmware update 0132:
http://www.cherry.de/files/software/TEM … B_0132.exe (standalone Windows flash executable only)
For me it worked properly so far and disabled this phantom key behavior. They said the firmware will be pushed to the upstream during the upcoming weeks.
Offline
Instead i called the Cherry support and they already have an experimental, unofficial firmware update 0132:
Hi Mojo,
yes, you're absolutely right. I also called Cherry support after I created this post. They were super helpful and gave me an unreleased version of the firmware. Once I see an official release, I'll post the link here...
Offline