swhkd brightness keys are not detected

Expected behavior: Brightness keys are detected and respond to keybinds.

Actual behavior: Brightness keys are not detected.

To Reproduce: set keybinds with xf86brightnessup

Mar 06 '22 07:03 Shinyzenith

for this to work we need to read events on video outputs...I don't know how to do that right now.

Mar 06 '22 07:03 Shinyzenith

it works fine for me.

XF86MonBrightnessUp
    xbacklight -inc 5

^Triggers as expected when pressing the brightness adjustment keys on my laptop.

Mar 06 '22 11:03 loiccoyle

it works fine for me.
XF86MonBrightnessUp
    xbacklight -inc 5
^Triggers as expected when pressing the brightness adjustment keys on my laptop.

what compositor are you on?

Mar 06 '22 12:03 Shinyzenith

I tried it on bspwm and river. Both the audio keys and the brightness keys work...

In testing I found there is a mistake for the xf86audioplay key it should be mapped to Key::KEY_PLAYPAUSE not Key::KEY_PLAY, but aside from that it works fine.

Mar 06 '22 12:03 loiccoyle

I tried it on bspwm and river. Both the audio keys and the brightness keys work...

In testing I found there is a mistake for the xf86audioplay key it should be mapped to Key::KEY_PLAYPAUSE not Key::KEY_PLAY, but aside from that it works fine.

On my device the brightness controls are emitted by the video outputs..might be hardware specific. ~~I changed it to playpause and it still doesn't work...might also be hardware specific so we probably need to bind to the other event file descriptors too.~~

Mar 06 '22 12:03 Shinyzenith

Hi,

@loiccoyle @Shinyzenith Would you mind testing again on the latest version to check if this is still an issue for you? I would be happy to try to fix it if it is still a problem!

Dec 18 '22 10:12 ajanon

Hi,

@loiccoyle @Shinyzenith Would you mind testing again on the latest version to check if this is still an issue for you? I would be happy to try to fix it if it is still a problem!

Sure thing! I'll try as soon as I get access to my laptop but the last time I checked with libinput debug logs, on some machines (such as my laptop) they are emitted by video devices.

Dec 18 '22 15:12 Shinyzenith

@ajanon Yep! this issue still occurs.

Dec 23 '22 13:12 Shinyzenith

The events are emitted by Video Bus according to the logs which is definitely not a keyboard aka one of our grabbed devices

Dec 23 '22 13:12 Shinyzenith

What happens if you forcibly grab the device with --device?

Dec 23 '22 13:12 ajanon

Upon grabbing forcibly with --device it does work once again.

Dec 23 '22 13:12 Shinyzenith

Should we drop the keyboard device detection now? Maybe it is not necessary anymore and we can just grab all devices.

Dec 23 '22 13:12 ajanon

Should we drop the keyboard device detection now? Maybe it is not necessary anymore and we can just grab all devices.

To be completely fair, the keyboard device detection has been extremely flawed to begin with! I think I agree with you, we should drop the check all-together and just parse the events we care about and re-emit the rest all through uinput.

Should we create an issue to track this? Note: Reminder to add to README/FAQ that all device configurations should henceforth be made to the uinput device instead of the specific devices due to swhkd's grab.

Dec 23 '22 13:12 Shinyzenith

I created issue #191 about this.

@Shinyzenith Feel free to add your reminder there!

Dec 23 '22 19:12 ajanon

Upon grabbing forcibly with --device it does work once again.

How do you grab the device with --device ? i am not understanding the concept

Apr 17 '23 11:04 RusticCraftsman

As a workaround, one can bind these to the proper commands using a Wayland compositor.

Jan 09 '24 12:01 rwmpelstilzchen