Binding special XF86 keys stopped working

[alerque]

I'm the maintainer of the Arch Linux packages for Hyprland and recently bumped them from 0.30.0 to 0.32.3 followed shortly thereafter by 0.33.0.

$ hyprctl version
Hyprland, built from branch HEAD at commit 3bb9c7c5cf4f2ee30bf821501499f2308d616f94  (props: bump ver to 0.33.0).
Tag: v0.33.0

flags: (if any)

Somewhere in the jump from 0.30.x to 0.32.x, I lost access to a number of bindings that worked fine before. Now 0.33.0 is showing the same problem and I'm trying to debug what happened.

For example:

bindl = , XF86AudioPlay, exec, playerctl play-pause

This is one example, but none of the XF86... keys I had bound before are working any more. All other bindings appear to work, just these went dead.

I've tried inspecting the activity with xev and wev and surprisingly neither shows any activity for the keys. I've also tried generating the inputs using xdotool which used to work, and those are not showing up either.

Any idea what happened to the input handling such that these keys might start getting ignored? Is there some wayland protocol stuff that changed and I might have packaged incorrectly or missed?

[alerque]

If relevant, my full Hyprland dotfiles are available here.

[vaxerski]

they definitely do seem to be working to me. If they aren't picked up by wev, it likely means hyprland is detecting them and consuming the input. Have you tried changing the command to e.g. kitty to verify it's not just playerctl not working?

[alerque]

Yes, I've verified playerctl is working when triggered from other key combos and tried other actions for the missing XF86____ keys. I also tried not binding the keys to see if they showed up in wev that way and got nothing. I'm not 100% sure if that testing actually worked though because I don't understand why some settings don't get cleared when removed from the config file. Perhaps there is an unbind operation I'm missing to clear all bindings before adding them from the config, or perhaps this testing needs more cold restarts.

[vaxerski]

when you reload a config: ALL settings get cleared: binds, rules, whatnot DEFAULT variables are loaded CONFIG is parsed and executed

anythign done with hyprctl is applied dynamically and will persist until the next reload (because point 1)

check hyprctl binds

[alerque]

The binding(s) exist, but the resolved keycode doesn't look valid.

bindl
        modmask: 0
        submap:
        key: XF86AudioPlay
        keycode: -1
        dispatcher: exec
        arg: playerctl play-pause

[alerque]

On the flip side, some other entries that show a keycode of -1 actually work, such as my Insert key bound to toggling a special workspace:

bind
        modmask: 0
        submap:
        key: Insert
        keycode: -1
        dispatcher: togglespecialworkspace
        arg: hyprake

That key works even with the odd keycode resolution. The XF86Audio* ones do not.

[vaxerski]

-1 means "no keycode" aka "you bound it via a keysym"

[VWoloszczuk]

Hi vaxry, I am now getting this issue on Hyprland 0.41.2 on Arch Linux 6.10.3.

About a month prior to this, I was able to see XF86* keys in wev, but no longer. This affects both my multimedia keys and the keys on my bluetooth headphones. I haven't used a keysym or changed any binds or config since then.

Please see below an extract from hyprctl binds. The first item is a multimedia key, the next four are from my BT headphones. None of these show in wev (although they all used to). These are all still doing their job except for XF86AudioPlay/Pause for some reason (not a hardware issue as they still work with my phone):

bind
    modmask: 0
    submap: 
    key: XF86MonBrightnessDown
    keycode: 0
    catchall: false
    description: 
    dispatcher: exec
    arg: brightnessctl s 10%-

bind
    modmask: 0
    submap: 
    key: XF86AudioNext
    keycode: 0
    catchall: false
    description: 
    dispatcher: exec
    arg: bash /home/viktor/bin/hypr/qmmp-bt.bash next

bind
    modmask: 0
    submap: 
    key: XF86AudioPrev
    keycode: 0
    catchall: false
    description: 
    dispatcher: exec
    arg: bash /home/viktor/bin/hypr/qmmp-bt.bash prev

bind
    modmask: 0
    submap: 
    key: XF86AudioPlay
    keycode: 0
    catchall: false
    description: 
    dispatcher: exec
    arg: bash /home/viktor/bin/hypr/qmmp-bt.bash pp

bind
    modmask: 0
    submap: 
    key: XF86AudioPause
    keycode: 0
    catchall: false
    description: 
    dispatcher: exec
    arg: bash /home/viktor/bin/hypr/qmmp-bt.bash pp

[vaxerski]

0.41.2 is old, try 0.42

[alerque]

"Old"? The new release is only a couple days old!

The Arch package for Hyprland (maintained by me) is at 0.41.2 right now, but 0.42 is in out testing repo. You can test it out from there, but me sure you grab the related hyprutils package from testing too, as well as the new aquamarine dependency:

$ pacman -U https://archlinux.org/packages/extra-testing/x86_64/hyprland/download/ https://archlinux.org/packages/extra-testing/x86_64/hyprutils/download/ https://archlinux.org/packages/extra/x86_64/aquamarine/

I haven't gotten a chance to test it much myself (being busy elsewhere) and I haven't gotten any testers to give feedback, so any :+1:/:-1: experiences welcome.

[vaxerski]

heh yea in distro terms thats new but since there is a huge diff between the releases with a lot of things changed it's worth testing it on 0.42

[VWoloszczuk]

Thanks for the advice, Vaxry and Alerque! Here are some comments from me:

• My XF86* binds are all working again
• They still don't show up in wev
• The wallpaper is now plain black instead of the old default wallpapers (which I hadn't changed yet)
• Start-up seems faster
• I also noticed a new glide-in animation for my waybar on startup - very sexy

Anyway, it gets a thumbs-up from me :) 👍 - much love!

[alerque]

I'm going to close this issue, but for the record I don't think we really know what was going on here.

I had this issue in 0.32 and 0.33. At some point after that they started working again, and I don't know which version that was. As of this second I'm on a machine still running 0.41.2 and they are working fine. I think it's been 3 or 4 versions at least that have been fine.

@VWoloszczuk I don't understand why you think you had this issue with 0.41.2 or why 0.42 would fix it, but I suspect we're chasing one or several device and env specific issues. I suggest any further instances of this behavior post as a new issue with keyboard specific info so we can do more targeted debugging. Clearly this isn't an issue that all XF86 keys are broken for everybody any more.