Kenny:

I have hacked wlsunset, adding two command-line parameters:

- one to run an external command on every set_temperature() (similarly
  to Robert Günzler's patch of 08-08-2022 but simpler and with different
  design choices), and

- the other to turn off talking to Wayland altogether.

My motivating use case:

I want wlsunset's (noninteractive) functionality, and I also want to be
able to invert my color map by keyboard command. Both functionalities
rely on wlroots' gamma control, but there can only be one such client
running at a time
(https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/2622). A neat
solution is to use one program (such as wl-gammarelay-rs, reading
commands from dbus) to do gamma control, and another program to compute
color temperatures and pass them to the former.

My question:

Are you interested in a patch (or in two separate patches)?

I used wlsunset for my purpose because I run sway, because wlsunset
appears to be popular among wlroots users, and because its code is very
compact and clean. However, my use case completely eliminates any direct
dependency on a graphical system. I could use any other redshift-like
program, or (more likely) create a new program by stripping wlsunset
down to just the temperature computation and external trigger. Having
such a minimal program would not be without merit but would entail
further code duplication. A middle ground would be to make it a
compile-time option, littering the code with #ifdefs.

Justus

Note that I have previously hacked up something somewhat similar: 
https://git.sr.ht/~kennylevinsen/execsunset - my use case was home 
automation at the time.

> Are you interested in a patch (or in two separate patches)?

Hmm, I'm not sure. I'm not currently opposed to Robert's patch (I just 
have been too busy to address it!), but wlsunset is mainly popular due 
to its simplicity in contrast to redshift/gammastep and its many 
backends, and making thing more complicated for wayland users of 
*wl*sunset might be unproductive.

Maybe a libsunset that takes care of all the math, so frontends could 
just be single-purpose? It could maybe contain the scheduling logic for 
convenience too.

> Both functionalities rely on wlroots' gamma control, but there can 
> only be one such client running at a time

The gamma API is not a good userspace API tbh, and if we get proper 
color space support it would either have to be simulated or have to be 
removed...

Note that daylight tracking will make no sense at all upon inversion, 
so you only want either wlsunset or inversion active at any given time. 
This could be done by replacing the process, or changing gamma-control 
so that the *last* client is in control (e.g. you can just run 
inversion and stop it when done, maybe with an event to wlsunset so it 
knows to resubmit gamma tables).

Best regards,
Kenny Levinsen

Kenny Levinsen <kl@kl.wtf> wrote on Tue, 23 Aug 2022 11:08:28 +0200:

Lots of great points above, but my bottom line is short:

> Note that daylight tracking will make no sense at all upon inversion,

Sure; wl-gammarelay-rs and probably all its likes invert the
temperature-adjusted gamma ramp. To do it right for this use case one
would have to temperature-adjust the inverted gamma ramp. Perhaps one
day I'll sit down and work out the math.

> so you only want either wlsunset or inversion active at any given
> time.

This gave me the right idea for an immediate solution: I just whipped up
a little shell script that toggles between running wlsunset and running
wl-gammarelay-rs, killing one and starting the other. Use case solved
(short of temperature-adjusting the inverted colormap, but this is still
better than my previous solution that inverted a temperature-adjusted
color map).

So many thanks for your comments :-)

Justus

On Tue Aug 23, 2022 at 10:44 AM CEST,  wrote:

> - one to run an external command on every set_temperature() (similarly
>   to Robert Günzler's patch of 08-08-2022 but simpler and with different
>   design choices)

even simpler and I thought I had stripped it down to the absolute
minimum to be able to run a script when the ramps are changing haha

On Tue Aug 23, 2022 at 11:08 AM CEST, Kenny Levinsen <kl@kl.wtf> wrote:

> Note that I have previously hacked up something somewhat similar: 
> https://git.sr.ht/~kennylevinsen/execsunset - my use case was home 
> automation at the time.

wow that's mostly what I was trying to do with my patch, although I
feel like plugging into this via the temperature is not that great from
a user perspective.

> wlsunset is mainly popular due to its simplicity in contrast to 
> redshift/gammastep and its many backends

came to wlsunset for exactly that reason, the only thing missing was
something that allows for hooking into what it is doing

> Maybe a libsunset that takes care of all the math, so frontends could 
> just be single-purpose? It could maybe contain the scheduling logic for 
> convenience too.

I like how this sounds, if only to get make it easier for more involved
tools to get this part right, considering that it might get more complicated 
in the future when the color management protocols land