danieldg

Pipewire supports the pulseaudio APIs for controlling volumes, and I believe this mechanism is still recommended by the pipewire authors (see https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#what-audio-api-do-you-recommend-to-use). I use pipewire on my system and it...

FYI: `RUST_LOG=debug rwaybar` already exists, though the documentation of this might need adding.

I use pulse to change volumes: ``` bindsym --locked XF86AudioRaiseVolume exec pactl set-sink-volume '@DEFAULT_SINK@' '+5%' ``` There are multiple "volume" knobs present in the pipewire (and pulse) path; I wonder...

Correction: the example config did not include scrolling to adjust volumes; this has now been added.

I think I'll want to make it threadsafe before doing that, but it's a good idea.

Note: I've not tried to reproduce, but I think this might be caused by swaylock not having an active window when all monitors are disconnected ("off" can sometimes mean "disconnected")....

FYI: this is fixed in 1.6 when used with compositors that support the lockscreen protocol (see https://github.com/swaywm/swaylock/pull/219 and https://github.com/swaywm/sway/pull/6879).

The OOM killer generally uses `SIGKILL`, so it won't trigger this. However, there are other processes that might automatically send `SIGTERM`; changing the unlock signal to `SIGUSR1` would prevent accidental...

> What is the use-case for the `--disable-unlock-on-sigusr` flag? Disabling the feature if it is unwanted. I think this was more relevant when it was on SIGTERM - with SIGUSR1...

I think this feature should be inverted and not a default feature - that is, make it a "no-auto-driver-thread" feature. Alternatively, it could just be a normal non-default feature with...