Certain Keyboard Hotkeys "disable" Keyboard-Input

Oddwierdo · 2023-07-29 17:22:25

I have a SKG3 Keyboard which has some additional Macros (that don't need any software) for example to change LED-Effects on the keyboard.
However pressing some of these (for example FNKey + Backslash) by accident causing Linux to stop recognizing any input from that keyboard (on Windows everything works as it should). The keyboard stays "powered on" though. Only a reboot then helps. I searched through journalctl though didn't find anything so far I even installed a virtual keyboard to check journalctl right after i pressed that combination though no new entry shows up. It happens on KDE X11 and Wayland, even switching sessions doesn't help - only a reboot fixes the issue.
Any idea how i can investigate this?

Last edited by Oddwierdo (2023-07-29 17:45:13)

Trilby · 2023-07-29 17:50:53

Watch output from dmesg (`dmesg -W`) and a key-event monitoring tool (e.g., xev under X11 or wev under wayland) while you press that key the first time.

Oddwierdo · 2023-07-29 18:09:17

Ty, i just tried that. Though no output from dmesg -W and the key event monitoring tool just reports the same as if i would press any other key (i would have taken a screenshot, though its super annoying doing that when i only can control the PC with my mouse until i reboot lol). I'd think my keyboard is just "broken". But on Windows this works without any problems.

Last edited by Oddwierdo (2023-07-29 18:09:41)

seth · 2023-07-29 19:35:00

3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

There doesn't seem to be a function attached to Fn+Backspace (judging from promo-images of the keyboard), but I guess it's programmable?
What's Fn+Backspace supposed to do?

Does it show the same behavior on the console (no GUI session)?
As for logging this:

sudo evtest | tee ~/skg3_events.log
xev -event keyboard  | tee ~/skg3_Xevents.log
sudo libinput debug-events | tee ~/skg3_input.log

No screenshots required or desired

Edit:

Only a reboot then helps.

Did you also try to un- and re-plug the keyboard?

Last edited by seth (2023-07-29 19:36:00)

Oddwierdo · 2023-07-29 21:09:50

I'm sorry i meant Fn+ = (though other combos casue it as well) it is supposed to change frequency of light effects which works. Though i don't care so much about these effects. I just don't want my keyboard to freeze when i accidently push the wrong keys .
I have fastboot, hibernation and all that stuff disabled on windows and didn't really boot windows for quite a while now. So i think that might not be related.

When logging with evtest i found out that there are 3 Versions of my Keyboard in the list. 1 seems to react only to normal input.. while another one only seems to record these combos/macros and the 3rd one doesn't react at all. So what i now found out by logging the "combo keyboard" is that it might work pressing a combo for the first time but pressing it again might cause an insane input loop. Heres a small example (list goes on forever and wont stop).

Testing ... (interrupt to exit)
Event: time 1690664432.144381, type 4 (EV_MSC), code 4 (MSC_SCAN), value c0401
Event: time 1690664432.144381, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1690664432.144381, -------------- SYN_REPORT ------------
Event: time 1690664432.399710, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 2
Event: time 1690664432.399710, -------------- SYN_REPORT ------------
Event: time 1690664432.436376, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 2
Event: time 1690664432.436376, -------------- SYN_REPORT ------------
Event: time 1690664432.473042, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 2
Event: time 1690664432.473042, -------------- SYN_REPORT ------------
Event: time 1690664432.513043, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 2
Event: time 1690664432.513043, -------------- SYN_REPORT ------------
Event: time 1690664432.553044, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 2

Last edited by Oddwierdo (2023-07-29 21:44:54)

seth · 2023-07-29 21:22:30

Please use [code][/code] tags. Edit your post in this regard.

The pattern looks like the key is stuck - not necessarily physically, but there's no release event.

on Windows everything works as it should … on Windows this works without any problems … didn't really boot windows for quite a while now

You still might want to investigate whether this (lack of release event) is a hardware problem first…

Oddwierdo · 2023-07-29 22:27:57

Okay, so there just doesn't really seem to be a solution to this. I have now again checked it on Windows to be certain, yet i can press they keys there all i want without running into this issue. I again got certain that i have disabled fastboot in Windows and Hibernation and rebooted several times. Still happens on linux. I guess i'll just give up on it an "live with it". Unplugging btw seems to help as well. So a reboot isn't nescesarry. Still sucks though.

seth · 2023-07-30 06:55:16

Does the key on windows also what you expect it to do?
What's the evtest report for just pressing and releasing Fn?
Does simply pressing and releasing Fn release the keyboard as well?

Is/are the specific macro(s) preset by the manufacturer or a customization?

Oddwierdo · 2023-07-30 10:30:14

*edit* sorry doublepost

Last edited by Oddwierdo (2023-07-30 10:55:37)

Oddwierdo · 2023-07-30 10:52:57

Yup the Key works as it should on windows. Fn-Key will show no input at all on evtest, only if it is combined with another key. I also found out, that it isn't the lack of a release event - it is just not detecting any new input at some point. Here's another example:

Event: time 1690713583.336060, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7000e
Event: time 1690713583.336060, type 1 (EV_KEY), code 37 (KEY_K), value 1
Event: time 1690713583.336060, -------------- SYN_REPORT ------------
Event: time 1690713583.536028, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7000e
Event: time 1690713583.536028, type 1 (EV_KEY), code 37 (KEY_K), value 0
Event: time 1690713583.536028, -------------- SYN_REPORT ------------

See? pressing the combo worked once - after pressing the combo another time (which also got recorded) no new input gets recorded and the only thing i can do is either reboot or reconnect the keyboard by unplugging it.

Another thing i've tested out of curiosity was trying the combu within the Uefi. But there it also doesn't happen so it seems to be exclusive to Linux. I also updated the Kernel but no luck issue remains.

The macros we're speaking about can't be changed so they are set by the manufacturer. Stuff like increasing volume, change lightning etc. Though it seems like only lightning related macros cause this issue to happen. For example changing volume didn't trigger the issue yet. I already suspected the Polling Rate of the Keyboard and tried different Polling Rates 125-1000Hz which didn't change anything. I then tried my luck changing the USB-Polling Interval according to the Arch-Wiki also no luck.

Last edited by Oddwierdo (2023-07-30 12:28:18)

seth · 2023-07-30 13:48:40

That's not the same as

Event: time 1690664432.144381, type 4 (EV_MSC), code 4 (MSC_SCAN), value c0401
Event: time 1690664432.144381, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1690664432.144381, -------------- SYN_REPORT ------------
Event: time 1690664432.399710, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 2
Event: time 1690664432.399710, -------------- SYN_REPORT ------------
Event: time 1690664432.436376, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 2
Event: time 1690664432.436376, -------------- SYN_REPORT ------------
Event: time 1690664432.473042, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 2
Event: time 1690664432.473042, -------------- SYN_REPORT ------------
Event: time 1690664432.513043, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 2
Event: time 1690664432.513043, -------------- SYN_REPORT ------------
Event: time 1690664432.553044, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 2

ad infinitum what is what you'll get when pressing and holding a key.

The new snippet simply shows you pressing and releasing the key for "k" (once)

Oddwierdo · 2023-07-30 14:23:01

You're right i messes that up and "monitored" the wrong event.
Do you think it might be related to the key being "unknown"? I tested for example next sound (which i do by pressing FN+F8) that won't show any issues. And print out:

Event: time 1690726921.091494, type 4 (EV_MSC), code 4 (MSC_SCAN), value c00b5
Event: time 1690726921.091494, type 1 (EV_KEY), code 163 (KEY_NEXTSONG), value 0

Last edited by Oddwierdo (2023-07-30 14:23:26)

seth · 2023-07-30 14:30:07

You can try to bind it to some actual keycode, https://wiki.archlinux.org/title/Map_sc … o_keycodes
But idk whether, why or how this would cause the key to be "stuck".

Oddwierdo · 2023-07-30 15:02:38

Okay tried it, again no luck. I think i'll give up on it now. I guess it is some kind of odd incompability. i btw even tested it on another linux system (using a Live USB) with the Same keyboard with the same results. A thing i should have mentioned is, that when using these lightning Macros the Keyboard somewhats "flickers" (Which is normal according to the manual). My blind guess would be that it "disconnects" for a split second or something like that causing that kind of issue. I guess linux shouldn't even recognize these combos since changing lightning by pressing these key-combos. I can change lightning by pressing these combos even when linux stopped recognizing input.
I also found out that all the key-combos causing this issue will show up with the same keycode (240). Which i think shouldn't be the case? Though at this point i don't know what to do anymore. I even tried disable these combos on Linux though it doesn't seem to work.

Anyways thank you for your patience on this, i really appreciate it.

Last edited by Oddwierdo (2023-07-30 15:27:15)

seth · 2023-07-30 15:43:15

My blind guess would be that it "disconnects" for a split second or something like that

You'd see that in "dmesg -W", I wonder whether that might cause a race condition that ends up w/ the interpretation of the key being stuck…

will show up with the same keycode (240). Which i think shouldn't be the case?

If they're keyboard internal functions and just "accidentally" generate events it doesn't really matter what the keycode is (though if the scancodes differ, you could intercept that and handle them separately on the OS level)

Oddwierdo · 2023-07-30 20:07:01

seth wrote:

If they're keyboard internal functions and just "accidentally" generate events it doesn't really matter what the keycode is (though if the scancodes differ, you could intercept that and handle them separately on the OS level)

It seems like the scancode is always the same (c0401) for all the problematic keys. I guess there is no chance to stop linux from detecting that keys? Maybe that would help since these keys don't have any function for the OS anyways. It seems to be an "inernal" binding only. That would also explain why predifined macros that actually control programs (like next song, increase volume..) don't suffer from that issue.

Last edited by Oddwierdo (2023-07-30 20:07:38)

seth · 2023-07-30 21:27:04

/usr/lib/udev/hwdb.d/60-keyboard.hwdb wrote:

16 # Supported hardware matches are:
17 # - Generic input devices match:
18 # evdev:input:bZZZZvYYYYpXXXXeWWWW-VVVV
19 # This matches on the kernel modalias of the input-device, mainly:
20 # ZZZZ is the bus-id (see /usr/include/linux/input.h BUS_*), YYYY, XXXX and
21 # WWWW are the 4-digit hex uppercase vendor, product and version ID and VVVV
22 # is a variable-length input-modalias describing the device capabilities.
23 # The vendor, product and version ID for a device node "eventX" is listed
24 # in /sys/class/input/eventX/device/id.
…
46 # To add local entries, create a new file
47 # /etc/udev/hwdb.d/61-keyboard-local.hwdb
48 # and add your rules there. To load the new rules execute (as root):
49 # systemd-hwdb update
50 # udevadm trigger /dev/input/eventXX
51 # where /dev/input/eventXX is the keyboard in question. If in doubt, simply use
52 # /dev/input/event* to reload all input rules.
…
66 # Scan codes are specified as:
67 # KEYBOARD_KEY_<hex scan code>=<key code identifier>
68 # The scan code should be expressed in hex lowercase. The key codes
69 # are retrieved and normalized from the kernel input API header.
70 # Keycodes are either KEY_* defines in lowercase with the key_ prefix
71 # optionally removed or BTN_ defines in lowercase with btn_ preserved.
72 #
73 # An '!' as the first character of the key identifier string
74 # will add the scan code to the AT keyboard's list of scan codes
75 # where the driver will synthesize a release event and not expect
76 # it to be generated by the hardware.

When you run "evtest" it'll ask you for the event device, eg. the relevant one would be "/dev/in/input/event2"

tail /sys/class/input/event2/device/id/* # use the correct event

Oddwierdo · 2023-08-01 09:22:20

Okay so i tried that. Though also - no luck. I guess it's just some kind of driver conflict or whatever. It seems like i can't do anything about it. Which is pretty pitty. Ty anyways.

Last edited by Oddwierdo (2023-08-01 09:42:49)

seth · 2023-08-01 11:54:14

You originally wrote:

Okay so i tried that. But it seems like i can't get Linux to actually accepting my changes.
My custom keyboard file looks like evdev:input:b0003v0c45p8513*
KEYBOARD_KEY_c0401=!reserved
i also tried different bindings, like reserved only or mapping othery keys according to the arch wiki
Though my changes just don't seem to get applied. I even tried replacing a key that works fine without any luck. I got certain that i use the correct Vendor and Product ID.
systemd-hwdb update seems to accept the changes however when reloading with udevadm trigger and checking with evetest the bindings stay the same. Any Idea what i'm doing wrong?

0c45 is the vendor ID of microdia and they seem to make webcams (which often have a keyboard/input device)
I'd double check on your assessment on the corect vendor/product ID (not saying that sharkoon doesn't use a webcan cheip there, it's just odd) and perhaps post

lsusb -tv

Oddwierdo · 2023-08-01 15:05:39

That wasn't the issue, the problem was that i wrote

evdev:input:b0003v0c45p8513*

instead of

evdev:input:b0003v0C45p8513*

I managed to block input on keys thatthat way. Though sadly didn't help for the issue. I have tested it so hard on Windows and even within the Uefi to reproduce it. There is just doesn't happen. It's exclusive to Linux it seems.
Only new "discovery" i made is that dmesg sometimes might print

keyboard: can't emulate rawmode for keycode 240

but i have no clue how that would help at this point. I guess i have tried everything i could at this point.

Last edited by Oddwierdo (2023-08-01 15:07:43)

seth · 2023-08-01 19:45:28

Can you please post the /etc/udev/hwdb.d/61-keyboard-local.hwdb you tried and did you successfully use it to alter the behavior of a working key (just to make sure you got it parsed)?

Oddwierdo · 2023-08-02 14:20:38

evdev:input:b0003v0C45p8513*
 KEYBOARD_KEY_c0401=!reserved
 KEYBOARD_KEY_c00b5=!reserved

First Key is the one which causing issues for me (the Scancode seems to be used on several RGB-Related internal Macros).
I used the 2nd Key in the list to test if i actually managed to "disable" the key that way. It is Fn+F8 (c00b5) and it was disabled (evetest and showkey wouldn't get any input from that key anymore) after

udevadm trigger

Last edited by Oddwierdo (2023-08-02 14:20:57)

seth · 2023-08-02 14:50:59

Does "KEYBOARD_KEY_c0401=!" work?

Oddwierdo · 2023-08-02 16:49:10

Tried it and doublechecked with

udevadm info /dev/input/by-path/*-usb-*-kbd | grep KEYBOARD_KEY                                                                                                                                  
E: KEYBOARD_KEY_c0401=!

yet after that, the key will stay detected and cause the same issue.

Last edited by Oddwierdo (2023-08-02 16:53:10)

Oddwierdo · 2023-08-03 16:34:21

Okay i made a new discovery: If connecting my Keyboard to a USB3 Port it will work and the issue wouldn't appear. Which is odd because it is a USB2 Keyboard and i had it connected to the USB that is actually made for keyboards (you know the one next to the PS/2 Port). So i guess it's somewhat of a driver Issue? Because on Windows it would work on USB2 Ports without this Issue. Do you know what could cause this to happen?

Though it would still spam console as soon as i press the combo.. though input would still work .

Last edited by Oddwierdo (2023-08-03 16:43:35)

Arch Linux

#1 2023-07-29 17:22:25

Certain Keyboard Hotkeys "disable" Keyboard-Input

#2 2023-07-29 17:50:53

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#3 2023-07-29 18:09:17

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#4 2023-07-29 19:35:00

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#5 2023-07-29 21:09:50

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#6 2023-07-29 21:22:30

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#7 2023-07-29 22:27:57

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#8 2023-07-30 06:55:16

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#9 2023-07-30 10:30:14

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#10 2023-07-30 10:52:57

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#11 2023-07-30 13:48:40

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#12 2023-07-30 14:23:01

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#13 2023-07-30 14:30:07

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#14 2023-07-30 15:02:38

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#15 2023-07-30 15:43:15

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#16 2023-07-30 20:07:01

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#17 2023-07-30 21:27:04

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#18 2023-08-01 09:22:20

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#19 2023-08-01 11:54:14

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#20 2023-08-01 15:05:39

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#21 2023-08-01 19:45:28

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#22 2023-08-02 14:20:38

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#23 2023-08-02 14:50:59

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#24 2023-08-02 16:49:10

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

#25 2023-08-03 16:34:21

Re: Certain Keyboard Hotkeys "disable" Keyboard-Input

Board footer