View Single Post
  #2   (View Single Post)  
Old 2nd April 2017
fvgit's Avatar
fvgit fvgit is offline
Spikes in tights
Join Date: May 2016
Location: perl -MMIME::Base64 -le 'print decode_base64("U2hlcndvb2QgRm9yZXN0")'
Posts: 217

Hi attilio,

I can confirm your observation regarding the xrandr command. I just tested it myself.

Let's have a closer look: if you re-read the manpage for xrandr(1) you'll see this:
--brightness brightness

Multiply the gamma values on the crtc currently attached to the output to specified floating value. Useful for overly bright or overly dim outputs. However, this is a software only modification, if your hardware has support to actually change the brightness, you will probably prefer to use xbacklight.
Thus the xrandr command will only adjust the colour brightness. Sth like:
$ xrandr --output LVDS1 --brightness 80
turns my screen into a 1980es fashion style nuclear accident. Whereas
$ xrandr --output LVDS1 --brightness 0.5
"dims" the screen by totally reducing all colour brightness (sw) without actually changing the brightness of the screen's backlight (hw). On a macbook you can check this nicely by looking at the transparent logo on the rear of the lid.
As you observed, xrandr's colour brightness setting is persistent when switching over to the console. Even after killing the X server(!). This is not the case with xbacklight(1)

When you're in an xterm and just type xbacklight what do you see? If it's a number, that would indicate the current hardware brightness value in % and you should be able to modify it. But if you see a message like
No outputs have backlight property
it may mean your machine doesn't support the hw brightness setting.

On my macbook both commands work, for instance:
xbacklight -set 80
wsconsctl display.brightness=20
However, when switching back to the console from X the wsconsctl(8) brightness value is reset to 100% (apparently this is a bug).
Reply With Quote