Keybinds for XF86* keys have stopped functioning

[eizengan]

Hyprland version

0.50.1

Regression

Yes

Describe the bug

Keybinds for XF86* keys have stopped functioning entirely. This appears to be an issue with Hyprland, as:

• The expected codes appear in showkey as the keys are pressed/released
• The commands bound to those keys still run as expected when directly invoked

Restoring default "allow all" keyboard permissions has no effect. Nothing is printed to the logs when debug output is enabled.

Reproduction steps

Add keybinds for such keys to your config, for example these from the default config:

bindel = ,XF86AudioRaiseVolume, exec, wpctl set-volume -l 1 @DEFAULT_AUDIO_SINK@ 5%+
bindel = ,XF86AudioLowerVolume, exec, wpctl set-volume @DEFAULT_AUDIO_SINK@ 5%-

and then press the corresponding key. The bound command will not be invoked.

System info and config

hyprland_systeminfo.txt

[vaxerski]

I can't repro this.

[eizengan]

Clarifying: can't as in repro doesn't work, or can't as in don't have those macro buttons available?

[eizengan]

Presumably the former. Is there a way to get any more insight into key events or binds from hyprland's point of view? Some command or log setting I'm not seeing?

[eizengan]

Turns out this was actually a keyboard permissions issue; my triaging was confounded by overlooking an important line in the wiki. Leaving a record for anyone who lands here via search:

• permissions are not reloaded when config is saved; this is clearly stated in the wiki
• enforce_permissions, however, is reloaded when config is saved - useful for triaging permissions issues
• the keyboard allowed in the attached systeminfo actually presents itself to hyprland as two separate devices
• the second device is not allowlisted before permission = .*, keyboard, deny

TLDR: if portions of your keyboard do not work after setting up keyboard permissions, make sure all of the devices it presents to hyprland are allowed.

[vaxerski]

enforce_permissions, however, is reloaded when config is saved - useful for triaging permissions issues

I should make it not do that...

[eizengan]

Probably a good idea. It would have made troubleshooting this difficult, though admittedly the wrench in those gears was ignorance. Would it be reasonable to have permissions denials add some context to the logs, perhaps?

[eizengan]

Hm; pretty sure I see logging present where permissions are checked. Possibly debug logs are only present when e.g. a flag is set during compilation - I'm not sure. If so, this feels like a nice candidate for the normal, rolling logs, as:

1. permissions behavior is user defined, and therefore prone to misconfiguration
2. not reloading permissions is safer, but unintuitive - particularly when triaging a misconfiguration
3. the first steps a user is likely to take having misconfigured their permissions are likely to disable permissions in the config and check the rolling logs

The status quo of "saving applies the new config" is working against us here; it would be nice to hedge against that

[vaxerski]

what we could do is make a popup that asks for the change to be applied, actually.

#11156

[eizengan]

Yeah, that rules - I would have had this figured out immediately