#[SOLVED] wl-gammarelay is not responsible on waybar

6 messages · Page 1 of 1 (latest)

novel dune
#

I'm a fan of eye comfort in the dark, so I started researching options for Arch. Landed on wl-gammarelay package, works like a charm, and even has waybar configuration examples! However, I'm apparently missing something.

The config example looks like this:

...
"modules-right": ["custom/wl-gammarelay-temperature"],
"custom/wl-gammarelay-temperature": {
    "format": "{} ",
    "exec": "wl-gammarelay --subscribe Temperature",
    "on-scroll-up": "busctl --user -- call rs.wl-gammarelay / rs.wl.gammarelay UpdateTemperature n +100",
    "on-scroll-down": "busctl --user -- call rs.wl-gammarelay / rs.wl.gammarelay UpdateTemperature n -100"
 },
...

First of all, the exec command doesn't work (when ran manually, returns "Failed to add match: Invalid match rule"), so I came up with something of my own:

...
"format": "{}K ",
"exec": "busctl --user introspect rs.wl-gammarelay / rs.wl.gammarelay | grep 'Temperature' | tail -n 1 | cut -d ' ' -f 19",
...

and it outputs the target result (see the screenshot below). But there's a problem: it's static. It's ran on the startup of waybar, it indeed grabs the current temperature, it even responds to scroll-up and scroll-down events, as well as keybinds which I configured for Hyprland. But in the current state it doesn't update on the bar.

#

This is what the waybar-custom(5) documentation has to say

interval:
typeof: integer
The interval (in seconds) in which the information gets polled.
Use once if you want to execute the module only on startup.
You can update it manually with a signal. If no interval or signal is defined, it is assumed that the out script loops itself.
If a signal is defined then the script will run once on startup and will only update with a signal.

So I obviously miss something between these lines. My command is indeed not a looped script, and when I set any interval, the problem fixes: scroll events are immediately responded to on the bar, and the keybind updates are followed by the interval timeouts (interval: 1, the command is pinged every second from the waybar startup, I press the keybind, by the end of the currently running interval the module on the bar is updated with the new value). But I don't like this solution: first, I want the module to respond "live" to my kebinds, similar to the scroll events, and second, I just don't like the fact that there will constantly be the command ping running in the background.

#

The other option I've got, aside from an interval, is a signal:

signal:
typeof: integer
The signal number used to update the module.
The number is valid between 1 and N, where SIGRTMIN+N = SIGRTMAX. If no interval is defined then a signal will be the only way to update the module.

But I'm not that enlightened yet, and the story with the signals confuses a little. I don't understand the signals essence, and I can't see how am I supposed to tinker with them to achieve the result that I'm after

#

I had googled the info on signals, but that didn't make it better in regards of understanding how should I use them

novel dune
#

Ay! I found a solution

#

I did my little research to understand what's going on and where, and here's what I found

So, the thing that was confusing me was the combination of me not knowing that pkill sends a signal, and is called kill because the default sent signal is SIGTERM, and also the fact that I didn't realize the signals used in waybar-custom(5) docs examples are not just any linux signals, but the real time (SIGRTMIN & SIGRTMAX) signals.

Back to the original problem, it is solved as simply as adding:

  • ..."signal": 7, # just any random RT signal that's not reserved for smth else... into the config of the custom module in .config/waybar/config
  • *command to change the temperature*; pkill -SIGRTMIN+7 waybar to the keybind in wherever you configure your keybinds (was .config/hypr/hyprland.conf for my case)

And that's it! The module now responds to the changes made by pressing the binds, as well as keeps its behaviour for the scroll-up and -down events :^)