swhkd
swhkd copied to clipboard
waycrate
Better keyboard device detection for key support should be done.
Version Information:
Linux laptop 5.17.8-arch1-1 #1 SMP PREEMPT Mon, 16 May 2022 20:45:27 +0000 x86_64 GNU/Linuxswhkd 1.2.0
Describe the bug: XF86Display, XF86Launch1 keys are not unsupported
Expected behavior: XF86Display, XF86Launch1 keys are supported
Actual behavior:
Config Error: Error parsing config file "/home/dith/.config/swhkd/swhkdrc". Unknown symbol at line 91.
Config Error: Error parsing config file "/home/dith/.config/swhkd/swhkdrc". Unknown symbol at line 94.
Lines 91-95:
XF86Display
xset dpms force suspend
XF86Launch1
xset dpms force suspend
To Reproduce:
Use XF86Display or XF86Launch1 key in config.
Additional information: From imported sxhkd config.
Thank you for your interest in the project, I will look into the following keys and implement them tomorrow.
Hi are you talking about this key? I see quite a few under display and I don't know what function the key serves.
https://docs.rs/evdev/latest/src/evdev/scancodes.rs.html Found nothing under the name launch, maybe it's under some other name? if you can find it above I can bind it. If it's not in that list, I can't bind that key.
From what evtest tells me, the key for XF86Launch1 is KEY_PROG1, and for XF86Display is KEY_SWITCHVIDEOMODE though I can't use them by default on my Thinkpad with swhkd because of this check:
https://github.com/waycrate/swhkd/blob/04e51255a4ef73151eac752c8c10dd51f1f30639/src/daemon.rs#L345
Both keys are in a separate device to the keyboard which does not contain an enter key:
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x17aa product 0x5054 version 0x4101
Input device name: "ThinkPad Extra Buttons"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 113 (KEY_MUTE)
Event code 114 (KEY_VOLUMEDOWN)
Event code 115 (KEY_VOLUMEUP)
Event code 120 (KEY_SCALE)
Event code 140 (KEY_CALC)
Event code 142 (KEY_SLEEP)
Event code 144 (KEY_FILE)
Event code 148 (KEY_PROG1)
Event code 152 (KEY_SCREENLOCK)
Event code 156 (KEY_BOOKMARKS)
Event code 158 (KEY_BACK)
Event code 171 (KEY_CONFIG)
Event code 173 (KEY_REFRESH)
Event code 190 (KEY_F20)
Event code 191 (KEY_F21)
Event code 194 (KEY_F24)
Event code 205 (KEY_SUSPEND)
Event code 212 (KEY_CAMERA)
Event code 217 (KEY_SEARCH)
Event code 224 (KEY_BRIGHTNESSDOWN)
Event code 225 (KEY_BRIGHTNESSUP)
Event code 227 (KEY_SWITCHVIDEOMODE)
Event code 228 (KEY_KBDILLUMTOGGLE)
Event code 236 (KEY_BATTERY)
Event code 237 (KEY_BLUETOOTH)
Event code 238 (KEY_WLAN)
Event code 240 (KEY_UNKNOWN)
Event code 372 (KEY_ZOOM)
Event code 374 (KEY_KEYBOARD)
Event code 444 (?)
Event code 445 (?)
Event code 446 (?)
Event code 466 (KEY_FN_F1)
Event code 475 (KEY_FN_F10)
Event code 476 (KEY_FN_F11)
Event code 485 (?)
Event code 582 (KEY_VOICECOMMAND)
Event code 592 (KEY_BRIGHTNESS_MIN)
Event code 634 (?)
Event type 4 (EV_MSC)
Event code 4 (MSC_SCAN)
Event type 5 (EV_SW)
Event code 3 (SW_RFKILL_ALL) state 1
Properties:
Testing ... (interrupt to exit)
If that check is modified so that this device is recognized as a keyboard by swhkd, KEY_PROG1 and KEY_SWITCHVIDEOMODE work.
(The modification I did for testing was just returning true except for swhkd virtual output devices, but that disabled my mouse :P )
(The modification I did for testing was just returning true except for swhkd virtual output devices, but that disabled my mouse :P )
That is because we use that function to get valid keyboard and then call kernel grab syscall, so when you hardcoded true, it grabbed your mouse too.
If that check is modified so that this device is recognized as a keyboard by swhkd, KEY_PROG1 and KEY_SWITCHVIDEOMODE work.
Understood. Do you have any ideas for better keyboard checking? Checking for key_enter is definitely not ideal.
Maybe detecting if something is not a keyboard? (Detecting if it's a mouse or joystick, etc.)
The only other type of detection I can think of is checking if it supports any possibly grabbable keys.
Maybe detecting if something is not a keyboard? (Detecting if it's a mouse or joystick, etc.)
Doesn't sound robust due to a couple reasons:
- We would need to hard code multiple device states.
- A lot of input devices share common characteristics such as buttons.
- Evdev also handles output devices so we would need to write cases for them too.
The only other type of detection I can think of is checking if it supports any possibly grabbable keys.
Afaik, key's aren't grab-able, output/input devices are.