Closed alerque closed 3 weeks ago
If relevant, my full Hyprland dotfiles are available here.
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?
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.
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
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
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.
-1 means "no keycode" aka "you bound it via a keysym"
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
0.41.2 is old, try 0.42
"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.
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
Thanks for the advice, Vaxry and Alerque! Here are some comments from me:
Anyway, it gets a thumbs-up from me :) 👍 - much love!
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.
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.
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:
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
andwev
and surprisingly neither shows any activity for the keys. I've also tried generating the inputs usingxdotool
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?