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