v1.10 doesn't have this issue, but in v1.11 the master branch, every time you execute manual mode, the temperature only gets redder until it reaches and remains at the limit of 1000K. E.g.
redshift -v -O 3000
Brightness: 1.00:1.00
Gamma (Daytime): 1.000, 1.000, 1.000
Gamma (Night): 1.000, 1.000, 1.000
Using method `randr'.
Color temperature: 3000K
redshift -O 3000
redshift -O 4000
Every call, even repeated values makes the screen redder. redshift -x does not reset.
I'm on Ubuntu 16.04
Thanks for reporting this issue. What is in your configuration file?
Config file is as follows. (I'm compiling for randr.) I've just finished what I think may be an acceptable fix, which relates to state->preserve: see https://github.com/jonls/redshift/pull/514
; Global settings for redshift
[redshift]
;brightness=0.9
; Configuration of the adjustment-method
; type 'redshift -m METHOD:help' to see the settings.
; ex: 'redshift -m randr:help'
; In this example, randr is configured to adjust screen 1.
; Note that the numbering starts from 0, so this is actually the
; second screen. If this option is not specified, Redshift will try
; to adjust _all_ screens.
[randr]
screen=0
This should be fixed with #537 although the -P switch should be used now with one-shot/manual mode to avoid applying the redness effect on top of the current gamma ramps. Reset mode works correctly without any additional options. Thanks for the suggestions in #514.
Maybe it's just me, but I while it is correctly documented (I admit I had to remind myself to RTFM after I've bisected the weird redshift behaviour) I think the current behaviour is counterintuitive and should not be the default for one-shot mode.
Examples:
redshift -O 5000redshift -O 6500redshift -O 5000redshift -O 4500Because, AFAIU, colour temperature is an absolute value. It should not be relative. The README-colorramp also suggests that.
Also, it breaks tools that use redshift (like the plasma applet), changes the commands people are used to and requires an additional parameter for an option that should be implicit.
While I might be wrong, the amount of issues popping up on this and other projects make me feel that more people are confused by this change.
I don't know the exact reason why the preserve option was introduced in the first place. For users who have to adjust their "default" gamma settings before using redshift? In this case, I'd prefer having this set in the config file or find another way to be able to distinguish between base gamma values, required by monitor or other circumstances and those set by redshift, altered every day.
"Preserve" was added because otherwise redshift blindly clobbers color controls, and in particular -x sets you to "uncalibrated" instead of "default profile". However, the implementation of the behavior is odd, and after a reboot it's not respecting the default profile with -x again, so shrug.
Most helpful comment
Maybe it's just me, but I while it is correctly documented (I admit I had to remind myself to RTFM after I've bisected the weird redshift behaviour) I think the current behaviour is counterintuitive and should not be the default for one-shot mode.
Examples:
redshift -O 5000redshift -O 6500redshift -O 5000redshift -O 4500Because, AFAIU, colour temperature is an absolute value. It should not be relative. The README-colorramp also suggests that.
Also, it breaks tools that use redshift (like the plasma applet), changes the commands people are used to and requires an additional parameter for an option that should be implicit.
While I might be wrong, the amount of issues popping up on this and other projects make me feel that more people are confused by this change.
I don't know the exact reason why the preserve option was introduced in the first place. For users who have to adjust their "default" gamma settings before using redshift? In this case, I'd prefer having this set in the config file or find another way to be able to distinguish between base gamma values, required by monitor or other circumstances and those set by redshift, altered every day.