-
-
Save jnettlet/afb20a048b8720f3b4eb8506d8b05643 to your computer and use it in GitHub Desktop.
| evdev:input:b*v0B05p193Ee0111* | |
| KEYBOARD_KEY_10081=reserved | |
| KEYBOARD_KEY_10082=reserved | |
| KEYBOARD_KEY_70070=reserved | |
| KEYBOARD_KEY_70071=reserved | |
| KEYBOARD_KEY_70072=reserved | |
| KEYBOARD_KEY_70073=reserved | |
| KEYBOARD_KEY_70074=reserved | |
| KEYBOARD_KEY_70075=reserved | |
| KEYBOARD_KEY_70076=reserved | |
| KEYBOARD_KEY_70077=reserved |
The values after KEYBOARD_KEY_ are scancodes, yes? How did you find out which scancodes needed to be set to reserved? Could you explain what keys lines 2 to 11 act on, and what setting a key to reserved means?
I want to learn how exactly this works.
For normal keys I can find scancodes with evtest, but the keys in the config above don't seem to be normally available on the keyboard.
Also, do you know if this can be done with keycodes instead of scancodes? If it can, how would it be done?
I think I found the answer in USB HID Usage Tables 1.5: https://usb.org/sites/default/files/hut1_5.pdf
I think 10081 and 10082 correspond to 81 and 82 (System Power Down and System Sleep) in Generic Desktop Page (0x01).
The ones beginning with 7 correspond to values in Keyboard/Keypad Page (0x07), right?
I think I found the answer in USB HID Usage Tables 1.5: https://usb.org/sites/default/files/hut1_5.pdf I think 10081 and 10082 correspond to 81 and 82 (System Power Down and System Sleep) in Generic Desktop Page (0x01).
The ones beginning with 7 correspond to values in Keyboard/Keypad Page (0x07), right?
Yes that is correct, however I have no idea why they are being sent simultaneous to the expected key codes. It could be a firmware bug, or maybe they trap the keycodes in their software and decided what keycode to pass to the host os depending on software settings. My main objective was just to get the keyboard functional under Linux.
Works perfectly on ChimeraOS. Thanks!
You can use my package https://aur.archlinux.org/packages/falchion-shutdown
On Fedora Workstation I also had to reboot. The
sudo systemd-hwdb updatedidn't seem to be enough. After the reboot though, it seems the issue is gone. This is pretty irritating as a matter of principle though and I'm now debating whether to return this keyboard. In any case, thank you for figuring this out!