have multiple brightness settings for different times of day.

[shirishag75]

Hi all,
I am using redshift 1.7.2 which has only two values for brightness which co-incide with day and night. It would be nice if we had an evening value-pair as well.

This is how it looks at my end :-

$ cat ~/.config/redshift.conf 
; Global settings for redshift
[redshift]
; Set the day and night screen temperatures
temp-day=5700
temp-night=3500

; Enable/Disable a smooth transition between day and night
; 0 will cause a direct change from day to night screen temperature. 
; 1 will gradually increase or decrease the screen temperature
transition=1

; Set the screen brightness. Default is 1.0
;brightness=0.9
; It is also possible to use different settings for day and night since version 1.8.
;brightness-day=0.7
;brightness-night=0.4
; Set the screen gamma (for all colors, or each color channel individually)
gamma=0.8
;gamma=0.8:0.7:0.8

; Set the location-provider: 'geoclue', 'gnome-clock', 'manual'
; type 'redshift -l list' to see possible values
; The location provider settings are in a different section.
location-provider=manual

; Set the adjustment-method: 'randr', 'vidmode'
; type 'redshift -m list' to see all possible values
; 'randr' is the preferred method, 'vidmode' is an older API
; but works in some cases when 'randr' does not.
; The adjustment method settings are in a different section.
adjustment-method=vidmode

; Configuration of the location-provider:
; type 'redshift -l PROVIDER:help' to see the settings
; ex: 'redshift -l manual:help'
 [manual]
 lat=18.5203
 lon=73.8567

; Configuration of the adjustment-method
; type 'redshift -m METHOD:help' to see the settings
; ex: 'redshift -m randr:help'
; In this example, vidmode is configured to adjust screen 1. 
; Note that the numbering starts from 0, so this is actually the second screen.
[vidmode]
screen=0

The above configuration file was stolen from the interweb somewhere. The only changes are/were the latitude and longitude readings and the screen 0 thing.

I did read that there is a difference between randr and vidmode but the configuration file shared didn't document what to do if randr is used. Should it be just :-

[randr]
screen=0

These are my values via xrandr :-

$ xrandr 
Screen 0: minimum 320 x 200, current 1600 x 900, maximum 32767 x 32767
VGA1 connected primary 1600x900+0+0 (normal left inverted right x axis y axis) 443mm x 249mm
1600x900       60.0*+
1400x1050      60.0  
1280x1024      75.0     60.0  
1440x900       59.9  
1280x800       59.8  
1152x864       75.0  
1024x768       75.1     70.1     60.0  
 832x624        74.6  
 800x600        72.2     75.0     60.3     56.2  
 640x480        75.0     72.8     66.7     60.0  
 720x400        70.1  

Looking forward to know more.

[maandree]

This is rather similar to issue #9.

I have not noticed difference between randr and vidmode,
except, vidmode can only modify the ramps on the primary
monitor (for each screen I think, but usually all monitors are
in the same screen) whereas randr can control all monitors,
individually. (Also I do not think vidmode can be used with
xcb which is faster and (if I recall correctly) uses less memory
(although produces more cluttered code) than xlib.)

[jonls]

Vidmode only has the concept of screens while RandR knows about both screens and outputs. Currently Redshift can only adjust individual RandR screens but an extension to control individual outputs separately has been proposed (#26) and there does not seem to be any technical obstacles to implementing this. From your xrandr output it seems you have one screen (Screen 0) and setting screen=0 in the configuration file would then only affect that screen. If you don't specify anything in the config file (let's say you remove the [randr] section entirely) then Redshift will affect all screens.

Regarding the brightness setting, I am somewhat unsure if it will be kept long term, though I have conceded that there may be valid reasons to use it in some cases. You should really stick with the normal backlight settings on your display if possible. The brightness adjustment imposed by Redshift is a kind of fake brightness using the gamma ramps.

Lastly, as @maandree mentioned there have been other proposals for custom time periods but it is hard to reach a consensus on what features should be supported in such a system. The solution may be that Redshift in the future supports a D-Bus interface that can be used by external programs to implement customized models. There is a sketch of this already implemented in the dbus-service branch.

[maandree]

@jonls
Perhaps you could add support for dynamically change the backlight. In linux this can be done by using the *brightness files in /sys/class/backlight/*, of course this must be optional as it may be unavailable or interfere with manual adjustment of backlighting.

[jonls]

@maandree I have considered that but I never got around to it. I originally ported xbacklight to xcb so that I could use the same code for Redshift but I never got further than that. (It got merged into upstream so if anyone wants to work on this the xbacklight code can be used as inspiration.) Also, as you mention, there is the problem that it interferes with the manual adjustment, which I don't see any easy solution to.

[maandree]

xbacklight method might be easier to use (I do know, I have never used xbacklight), but it does not work on all devices. The only solution a can see to the interference is to check for changes before adjusting. Another problem with backlight, at least if you use /sys/class/backlight is that you might few levels (it is device dependent, on my laptop I have 100 if a use the video driver, but 5 if a use acpi). Using /sys/class/backlight have two interesting properties: it does not require X so you could use redshift without X with the restriction that it only changes the backlight; and you need root (using setuid mode flag will remove this restriction [requires a compiled command, which redshift is]) or the permissions in /sys/class/backlight needs to be adjusted.

Also if you are interested in identifying monitors uniquely, I have implemented EDID detection written with XCB in C: https://github.com/maandree/blueshift/blob/master/src/blueshift_idcrtc.c

[jonls]

Thanks, I assumed the xbacklight method would be more portable since it seems to be one layer above. Not having to deal with permissions would be an advantage. Both methods should be possible though.

[RafalBabinicz]

Here is my perspective.
I’ve had many problems with xbacklight and currently I can only use sysfs based solution [2].

IIRC from discussion with xf86-video-ati developers

• driver for my chip does not provide brightness control via XRandR (which is needed by xbacklight).

I’m able to change brightness with sysfs:
echo 1 >! /sys/class/backlight/asus_laptop/device/backlight/asus_laptop/brightness

Currently I’m using @maandree adjbacklight for convenience.

My point is:
backlight support is a total mess, which you can see by reading [1]

Resources:

[1] https://wiki.archlinux.org/index.php/backlight is an excellent summary of backlight problems and possible solutions.
[2] https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight
[3] https://bugs.archlinux.org/task/27677
[4] https://wiki.archlinux.org/index.php/acpid#Enabling_backlight_control
[5] https://wiki.archlinux.org/index.php/xorg
[6] https://code.google.com/p/bltool/
[7] http://haikarainen.dotgeek.org/lightscript/
[8] https://github.com/maandree/adjbacklight
[9] https://wiki.archlinux.org/index.php/ATI

My current setup:

Graphics: Card: Advanced Micro Devices [AMD/ATI] RV530/M56-P [Mobility Radeon X1600]
Display Server: X.Org 1.15.0 drivers: ati,radeon Resolution: 1280x800@60.00hz
GLX Renderer: Gallium 0.4 on ATI RV530 GLX Version: 2.1 Mesa 10.1.0
System: Host: potop Kernel: 3.14.0-3-ARCH x86_64 (64 bit) Desktop: N/A Distro: Arch Linux

[maandree]

Because of the mess backlighting is I suggest not implementing it.
When D-Bus service is implemented, a client could easily get the
brightness settings and set them to 1:1 and take care of backlighting
with would make it easier to select what technique to use without
redshift having to support all of them.