Bugzilla – Bug 3483
xset dpms force off does not turn off LCD backlight
Last modified: 2007-08-31 07:11:30 UTC
"xset dpms force off" blank the screen, but the LCD backlight is still on, and
the monitor is not in standby mode (green light on my Dell 2001FP, instead of
Tested with Radeon 9100 IGP, DVI-D connection, Dell 2001FP LCD.
Possibly related to #1666.
Similar behaviour here. On a ThinkPad T30, "xset dpms force off" just blanks the
screen, but doesn't turn off the backlight. This is particulary annoying when
trying to use suspend-to-RAM as the screen remains still on after suspending.
Even closing the lid doesn't help.
Radeontool (http://fdd.com/software/radeon/) (probably) did the trick. I can't
really tell whether it shuts off the whole monitor or just turns the backlight
off. (Or is it essentially the same?)
Maybe it would be possible to incorporate this functionality into the radeon driver?
I have the exact same problem, with a Radeon X600 connected to a Dell 1901FP LCD
monitor via the DVI connector.
From a Linux framebuffer, if I enable DPMS:
$ setterm -powersave powerdown -powerdown 1
...and then wait for DPMS to kick in, the LCD backlight turns off, and the power
light changes from solid green (full on) to solid yellow (off), which is correct
This is under Fedora Core 5, using:
$ rpm -q xorg-x11-server-Xorg
(I also have FC5 running on my laptop (a Dell Latitude D610 with a Radeon
Mobility card) with the same version of Xorg, and I do *not* experience this
problem there. I've only experienced this problem with the Radeon X600 paired
with the Dell 1901FP LCD monitor.)
Created attachment 6023 [details]
My Radeon X600 xorg.conf file.
Created attachment 6024 [details]
My Radeon X600 xorg.conf file.
Created attachment 6025 [details]
My Radeon X600 Xorg.0.log file.
Please ignore the obsoleted xorg.conf file; that was from the wrong machine.
(In reply to comment #3)
> From a Linux framebuffer, if I enable DPMS: [...]
If that's with radeonfb, have you tried Option "UseFBDev" with X?
I wasn't using radeonfb; I was just using the plain old Linux console (e.g., tty1).
Another data point: just out of curiosity, I temporarily switched from the DVI
cable (digital display input) to the VGA cable (analog display input), and DPMS
So, at least for my Radeon X600 and Dell 1901FP LCD monitor, DPMS fails to
function only when using digital display input.
I second the previous comment. D-Sub connection doesn't have this problem.
Tested with Radeon 9100 IGP and Dell 2001FP LCD.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
I can confirm this for my Dell Inspiron 8200 with "Radeon R250 [Mobility FireGL 9000]".
I think DPMS suspend -> off drops powerconsumption approximately 1 watt.
Switching off the backlight with radeontool drops the power consumption an additional 4(!) watts. That's a lot for a dinky laptop battery.
This is current released bits + current randr 1.2 branch of the radeon driver.
I did some closer observations. The drop in power consumption between suspend and off may have been wishful thinking.
Numbers taken from powertop:
fully lit, panel on = 26 watts
blank = 20-21 watts
suspend = 20-21 watts
standby = 20-21 watts
off = 20+ watts (not significantly less than suspend/standby, I think)
radeontool light off = 16 watts
The driver will happily restore light when I press a key, so it looks like the driver plays with the (some of) same registers as radeontool.
I also notice that the Fn-brighter/Fn-darker keycombos doesn't work from within X. They do work in the virtual console, though. Should I open a separate bug for this?
One more observation. backlight is *not* restored whe hitting a key in the virtual console. Thus I think it is reasonable to conclude that it is the driver which restores the backlight, and not the BIOS.
fixed for LVDS in master and randr-1.2
Tested. works for me. James, do you care to test as well, being the original reporter and all...
Otherwise, I'd say the bug is ripe for closing.