Reloading of settings

[maandree]

The patch enables to user to send SIGUSR2 or use redshift-gtk to load new settings from redshift.conf. It is configurable whether the new settings should kick in directly or if there should be a short transition to them.

Currently only adjustment settings are reloaded, but this could be extended to include location, monitors and adjustment method.

[rudolfbyker]

Any chance to get this merged in 2017? Need any help to get this done?

[mapreri]

I'd also love to see this one merged. Having a signal available to reload the config is completely orthogonal to any switch (or button in redshift-gtk) like the ones mentioned in #194, and would make my life while testing new options and stuff much easier.

Is anything blocking this? There hasn't been even a single comment from a maintainer.

[jonls]

This is a neat feature but I don't think it's useful to most users so I'm not sure if the added complexity is worth merging. It looks like the implementation here doesn't try to handle changes to the adjustment method/location provider. I suspect this is going to lead to confusion if we only reload some parts of the configuration file. In any case, the current PR needs to rebase because the options system has been implemented in the meantime.

[dimaqq]

@jonls I'd gladly use signal-to-reload config, or even poll-config-file-for-changes. I'm using redshift without gtk and editing the redshift.conf seems to be the only way to change settings. Btw., I'd rather expect SIGHUP to reload config than SIGUSR2.

[dbedrenko]

I'll describe a usecase that makes this a useful feature.

Since Redshift seems to override xrandr settings, e.g. if you change the brightness of your display via xrandr --output eDP-1 --brightness .2 it will momentarily reset the colour temperature that Redshift had set and set the desired brightness, but a split second later Redshift kicks it back to what it was before. Due to this behaviour it's not possible to adjust the brightness of the display without restarting Redshift with a different brightness parameter.

This feature would allow changing brightness seamlessly and on the fly. Currently, to change brightness--like if I moved to another room or the lighting changed--I have to kill redshift and restart it with a different brightness, which is a pain.

[StephenBeirlaen]

This would be very useful on machines with an OLED display where the brightness slider of the OS is not functioning due the lack of a backlight. I would then be able to add key bindings to these brightness buttons to set the Redshift brightness value, and then make Redshift reload the new settings. I attempted to rebase this PR but failed, the main codebase has changed a lot over time.

[shanemd]

Interested in something like this getting in. Mostly I don't like that terminating redshift spikes my screen color temperature while I'm changing settings. I'd interact with redshift a lot more if I could make changes without blasting myself with blue light.

Any help needed here? I'm happy to lend a quick hand.

[aiguofer]

I'm trying out xidlehooks, which has the ability to run various hooks on timers at different times. I really like the idea of being able to dim my screen after a few minutes, but this is currently not possible with redshift managed by systemd (see @dbedrenko's comment). I would love some way to do this that doesn't involve a hacky script to to sed the config file, change a setting, then restart the systemd service... I'm not a fan of the blue light flash.

I think a socket based client would be ideal. It would allow for easily writing scripts to change color temp, brightness, etc on the fly. That being said, I would be ok with sed scripts to overwrite values if they get automatically picked up.