Open l0b0 opened 10 years ago
xbacklight does not work for everyone, and to be it appears that it works for very few, and that sysfs works better. However sysfs does not map trivially map to monitors, and xbacklight work on all monitor collectively and not separately (I'm not sure if the protocol does but the utility does; however we could choose to only use it when all monitors should have the same brightness, which is probably always for most people.) That there most be an option to enable (or perhaps disable) it explicitly because we cannot be sure if it works (just like we cannot be sure that the gamma adjustments actually work.) Personally I think it would be better to use sysfs than xbacklight, but using both is best. But I think it renders too much cruft and that it is better to stick with the current method that is sure to work for everyone as long as redshift works and is needed anyway for people that do not have monitors with adjustable backlight. But when the D-Bus support is completed, xbacklight could be added by a separate program.
If you want backlight support you could look at putting together https://github.com/maandree/blueshift/blob/master/examples/comprehensive and https://github.com/maandree/blueshift/blob/master/examples/backlight, but that uses sysfs rather xbacklight, but it does probably work, if not, you could script it to call xbacklight.
Thanks for the feedback! I'm afraid my knowledge of C is rather minimal, so I suspect I would be a bad candidate for implementing this.
My suggestion at the end is in Python 3.
I just thought if an other issue with backlight, some drivers/devices will malfunction if the brightness because too low (I think zero) and will get stuck at complete blackness until the computer is rebooted. So if backlight is ever implemented, one would have to think about this.
Thanks for providing a good explanation @maandree. I think it should also be added that using backlight also comes with a bunch of other open questions about what should happen if the user tries to adjust the backlight while redshift is running.
i chown/chmod /sys/class/backlight/radeon_bl0/brightness to my user at boot, then use the hook:
bash-4.3$ cat ~/.config/redshift/hooks/brightness.sh https://gist.github.com/nickabal/0a3faaa45b76a53bfad76a748e27b58f
would be great if redshift support backlight adjustment. currently I run xbacklight using crontab
Hi everyone, I read this issue a few times and I decided the create a pull request with a possible implementation. I really love how redshift works (thanks!) and having backlight support will be awesome.
The pull request, however, is just a prototype to have an open discussion. It is not ready as @maandree and @jonls mentioned, this is not a trivial task.
PR: https://github.com/jonls/redshift/pull/506 (closed, see PR #512)
Any comment or suggestion will be really helpful.
For example, should the backlight be a property in redshift by its own or we should reuse the brightness? If the latter, the user control the brightness as usual but instead of modifying the gamma adjustments we modify the backlight property directly via sysfs.
Thanks!
I created the definitive PR #512. You can enable the backlight support using -k
and selecting a sysfs path to the controller. The brightness is still controlled by -b
but when the backlight is active it will not modify the gamma ramps but the monitor's backlight instead.
Example:
redshift -b 0.7:0.3 -k /sys/class/backlight/intel_backlight
Further details and caveats are described in the PR #512 . I really like to hear of you and see if we can improve this a little further.
It will be an honor for me to contribute to this project.
Both PRs were closed :C are there any updates on this?
I keep manually adjusting the backlight with
xbacklight -set N
; it would be great ifredshift
used the same method for the brightness adjustment where available.