Repro:
$ for i in {1..200}; do redshift -O 6000; done
Expected: Screen filter is set to 6000K
Actual: Screen is totally red
In redshift 1.11, one-shot mode would set the screen filter's intensity to the provided argument regardless of how many times it was called. Now, calling it multiple times without redshift -x in between appears to increase the intensity per-call.
This change wasn't in the release notes, so I'm assuming it's a bug. This happens to both color temperature and brightness (when called with -O ... -b ...)
AdamNiederer
All 5 comments
Seems like it's not resetting the old redshift setting before setting it again; if you use a value below 6500K and then set a value above 6500K, the screen brightness will start to decrease.
vicr123
on 24 May 2018
Git bisect suggests that the issue was introduced in commit dcafe503d3670bb6b922a3235d80b9e48e5b3ca7 from pull request #511 related to preserving gamma ramps by default (this bug could affect other methods as well since this pull covers others).
mattjohnruss
on 24 May 2018
Ah, just found this closed issue https://github.com/jonls/redshift/issues/513 which seems to be pretty much a duplicate? The "bug" seems to be the intended behaviour and using the "-P" with one-shot mode as @jonls suggests here (https://github.com/jonls/redshift/issues/513#issuecomment-337125923) makes the issue disappear for me.
mattjohnruss
on 24 May 2018
Yes, using -P should work for this.
jonls
on 24 May 2018
I might question whether the new behavior is a sensible default in the first place, but the larger issue is that the api was broken without warning and (compared to adding a flag for the new behavior) without apparent benefit.
Users are going to experience this as a bug, regardless of whether it was intentional. Although there is a workaround (-P), it would obviously be preferable to fix it upstream, rather than confusing users and wasting their time.
This is not a good experience. Considering some larger distros have yet to pick up the update (and some users will have held it back, thinking the bug will disappear in the next release), I think it is worth reconsidering how this issue is treated.
gavtroy
on 9 Jun 2018
Related issues
xxcriticxx
路
3Comments
cbcoutinho
路
6Comments
freedomd1v3
路
4Comments
6arms1leg
路
5Comments
gamalan
路
4Comments
Most helpful comment
I might question whether the new behavior is a sensible default in the first place, but the larger issue is that the api was broken without warning and (compared to adding a flag for the new behavior) without apparent benefit.
Users are going to experience this as a bug, regardless of whether it was intentional. Although there is a workaround (-P), it would obviously be preferable to fix it upstream, rather than confusing users and wasting their time.
This is not a good experience. Considering some larger distros have yet to pick up the update (and some users will have held it back, thinking the bug will disappear in the next release), I think it is worth reconsidering how this issue is treated.