waycrate / swhkd

Sxhkd clone for Wayland (works on TTY and X11 too)
https://git.sr.ht/~shinyzenith/swhkd
BSD 2-Clause "Simplified" License
676 stars 47 forks source link

Better keyboard device detection for key support should be done. #126

Open dithpri opened 2 years ago

dithpri commented 2 years ago

Version Information:

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.

Shinyzenith commented 2 years ago

Thank you for your interest in the project, I will look into the following keys and implement them tomorrow.

Shinyzenith commented 2 years ago

image Hi are you talking about this key? I see quite a few under display and I don't know what function the key serves.

Shinyzenith commented 2 years ago

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.

dithpri commented 2 years ago

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 )

Shinyzenith commented 2 years ago

(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.

dithpri commented 2 years ago

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.

Shinyzenith commented 2 years ago

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:

  1. We would need to hard code multiple device states.
  2. A lot of input devices share common characteristics such as buttons.
  3. Evdev also handles output devices so we would need to write cases for them too.
Shinyzenith commented 2 years ago

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.