Sway / Waybar / SwayOSD Keybind Weirdness 🤔

Desktop Environments All WMs
1

I hesitate to post this as it’s likely something stupid I keep overlooking…

Issue: Sometimes the keybind’ings to control sound, brightness, capslock, numlock, and the associated OSD popup messages all work great.

Other times the keys don’t respond at all - neither visually nor functionally.

Additional observations: When they’re working just fine and THEN I logoff - when I immediately log back in again they are no longer responding.

If I reboot, sometimes they come back and sometimes they don’t … but it often takes multiple reboots to resolve. Same if I fully shut down and power back up. :man_shrugging:

I can never predict when they’re going to function and when they won’t. If they’re working, they keep working consistently throughout that session. If they aren’t, I have yet to find a way to resurrect them.

This has been observed on 3 different installations of sway/waybar/swayosd all of which are using the same set of config files I’ve copied over. ('11 MacBookPro, '19 iMac, Dell Optiplex 7010).

In all cases (whether the keys are working or not) I’ve confirmed: systemctl status swayosd-libinput-backend.service shows the service is active and running on all three systems.

Checking journalctl -b for bootup errors related to SwayOSD always shows successful loading – even in those cases where the keys are unresponsive.

If I open pavucontrol (either through terminal or clicking on waybar sound section), I can manually drag volume and un/mute sound this way. It functions as expected. And the pulseaudio section of the waybar responds visually to those changes, too.

But when the issue is occurring, there’s just no response from the volume/mute keys (or brightness control keys). I’ve also tried both with and without the “fn” function key (to avoid inadvertently sending F1, F2, …F12 instead of the media functions).

Question: Any ideas come to mind that would produce the same intermittent problem - on three different installations?

2

What are your current keybinds? It’s been a while seen I ran sway as my daily driver, but I don’t remember this being an issue. Tbh, though, I had never heard of swayosd until @joekamprad’s latest dotfiles.

3

I’ve been using swayosd for at least 6 months now, i have so many problems with it and no solutions i’m currently looking for a replacement… I’m afraid i can’t help here…

4

I think I had went with DankMaterialShell very early on in my time with sway; had too many problems with waybar and swaync.

@ArchieLinux - is that a possible solution for you? DMS (or Noctalia) is great for handling stuff like OSDs, as well as many other things.

5

i do use swayosd for longher time here and not really have issues with it, and also not with keybinds ?
Basically only created a style.css for it

6

Same here… Although swayosd is involved as part of the larger sway ecosystem, I haven’t edited it in any way - it’s out of the box. And I am using your own EOS purple theme style.css with it as you’ve provided - Thanks!). No editing on my part to either.

My keyboard bindings have been made in sway’s config.d directory’s keybindings file with stylings and on-click assignments made within waybar’s config and associated style.css.

The on-click waybar assignment for sound remains the standard pavucontrol without changing it from stock. It appears in the pulseaudio section of waybar’s config file, per stock.

@joekamprad : Do you have consistent successful use of your keyboard to control sound volume and mute, and monitor brightness? Which make/model keyboard are you using?

Fwiw, of the 3 installations which are all misbehaving intermittently, one is a 2011 MacBook laptop integrated Apple keyboard. The other two are different sized models of Keychron mechanical keyboards (one with a 2019 iMac; the other on an old Dell tower - whether I set them to MacOs or Win configuration switch.)

7

UPDATE: At least for now…

I’ve enabled the various media keys to successfully function (i.e., controlling the volume/mute and monitor brightness) by modifying the ~/.config/sway/config.d/keybindings file to directly associate each bindsym XF86xxxx... key to an explicit exec brightnessctl… or exec pactl… command (instead of an exec swayosd-client command).

As a result (unlike the numlock and capslock keys, whose states continue to be reported on-screen via swayosd) there is no swayosd on-screen reporting of changed levels of these media function keys.

However, the associated waybar sections do instantly reflect any such changes from the media keys (and the sound control works, and the monitor dims/brightens accordingly, too).

I’ll keep exploring how to get swayosd to properly participate (by reporting) changes in these functions on a consistently reliable basis - resolving the intermittent and function-killing behavior.

One attempt: tying the commands in keybindings config file to swayosd-client brings me back to getting no response from the key strokes.

Another attempt: Tying the symbind execs to both swayosd-client and pactl or brightnessctl creates an error report when logging in to sway because of duplicate key assignments - so that’s a go-no.

Will report back on any further progress - if achieved - for benefit of future travelers. :vulcan_salute:

8

i do use sway on different devices, but i can see it does properly show swayosd with the xf86 audio keys on the Desktop and on Notebook it does the same for both brightness and audio volume.
Could be a keymapping issue ?