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:
Quote:
--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:
Code:
$ xrandr --output LVDS1 --brightness 80
turns my screen into a 1980es fashion style nuclear accident. Whereas
Code:
$ 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
Quote:
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:
or
Code:
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).