brightness keys are not detected

[Shinyzenith]

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

Actual behavior:
Brightness keys are not detected.

To Reproduce:
set keybinds with xf86brightnessup

[Shinyzenith]

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

[loiccoyle]

it works fine for me.

XF86MonBrightnessUp
    xbacklight -inc 5

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

[Shinyzenith]

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?

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

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

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.

[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!

[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!

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.

[Shinyzenith]

@ajanon Yep! this issue still occurs.

[Shinyzenith]

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

[ajanon]

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

[Shinyzenith]

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

[ajanon]

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

[Shinyzenith]

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.

[ajanon]

I created issue #191 about this.

@Shinyzenith Feel free to add your reminder there!

[RusticCraftsman]

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

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

[rwmpelstilzchen]

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