Red Hat Bugzilla – Bug 508558
xset dpms force off stopped working - no blanking
Last modified: 2010-02-08 20:21:14 EST
Description of problem:
xset dpms force off does nothing
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. type "xset dpms force off" in terminal
screen blanks (and goes into low power mode)
This has worked for a couple of years with this driver (and more years with the fglrx driver), until now.
I'm not sure that the driver is the problem. It could be the kernel
or something else. But, if it is the kernel, it seems to be specific to x86_64 and/or this driver, as my i586 laptop (with an ibm card) works fine with the same kernel version.
I make sure to start dpms by using xorg.conf, and Xorg.0.log, xdpyinfo, and "dpms q" all say that dpms is on.
vbetool also did nothing.
Xorg.0.log says that the graphics card is
ATI Technologies Inc RV380 [Radeon X600 (PCIE)]
and the monitor is DELL 2405FPW driven through DVI (according to xrandr)
The bug is a result of the new kernel. If I reboot using
The new kernel that causes the problem is
I have the same problem: xset dmps force off does nothing.
I have Thinkpad R50p, which has ATI Technologies Inc M10 NT [FireGL Mobility T2] graphics card.
I have kernel-188.8.131.52-191.fc11.i586, so the bug is not only on x86_64.
The command "xset dmps force off" works with kernel-184.108.40.206-167.fc11.i586 but not with kernel-220.127.116.11-191.fc11.i586 on my Thinkpad R50p.
I have yum update'd my system to the latest versions.
Please note that the platform of this bug is wrong: I can reproduce it on x86.
The command "xset dmps force off" works with kernel-18.104.22.168-191.fc11.i586 for the following two laptops:
Acer Aspire 9301AWSMi: nVidia Corporation MCP51 PCI-X GeForce Go 6100 rev 162 (using xorg-x11-drv-nvidia-185.18.14-2.fc11.i586)
Packard Bell: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller rev 9
So it seems that the combination of ATI and kernel-22.214.171.124-191.fc11.* does not work. Please note that with Thinkpad R50p (see my posts yesterday) I used the radeon driver, not the fglrx driver.
I'm seeing this too with kernel 126.96.36.199-191.fc11.i686.PAE on my old Dell XPS workstation, using the radeon driver.
Say, this is interesting:
While Googling about this problem yesterday I stumbled across something sorta related: the nomodeset kernel option for improving my graphics card's 3d performance. After I added nomodeset and rebooted, DPMS unexpectedly started working again (and 3d performance was much better, natch).
Adding nomodeset worked for me too! (Not quite sure what this does, but it also, IMHO, improved the boot process, going back to the old-fashioned console with nice readable font instead of the minuscule font it has been using.) Not sure about 3D; I don't think I use it.
BTW, this bug is almost certainly in the radeon module that is part of the kernel, and not in xorg-x11-drv-ati (where I originally thought it was when I reported it), possibly somewhere like
Perhaps someone should change it. I hesitate to try to do that, since it has already been "assigned."
When using kernel version 188.8.131.52-167.fc11
dpms blanking works fine, it does not work when booting
kernel-184.108.40.206-213.fc11.i586 (or the .5 kernel)
Random data point: with the following configuration the screen will not blank with DPMS if kernel modesetting is used; it works fine with the nomodeset kernel option.
ATI Technologies Inc RV516 [Radeon X1300/X1550 Series] (ChipID = 0x7183)
ATI Technologies Inc Radeon R200 QH [Radeon 8500] (rev 80)
Works with nomodeset, doesn't work without.
ATI Technologies Inc RV380 [Radeon X600 (PCIE)] rev 0
"xset dmps force off" works with nomodeset, doesn't work without.
Created attachment 364685 [details]
Patch fixing DPMS issues
The attached patch fixes the problem for me on this r200 chip:
05:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01) (prog-if 00 [VGA controller])
Subsystem: VISIONTEK Device 7c13
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
Memory at e0000000 (32-bit, prefetchable) [size=128M]
I/O ports at c000 [size=256]
Memory at feaf0000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at feac0000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: radeon
Kernel modules: radeon, radeonfb
05:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200] (Secondary) (rev 01)
Subsystem: VISIONTEK Device 7c12
Flags: bus master, 66MHz, medium devsel, latency 64
Memory at d8000000 (32-bit, prefetchable) [size=128M]
Memory at feae0000 (32-bit, non-prefetchable) [size=64K]
Capabilities: <access denied>
Patch applies to all released kernels (2.6.29-2.6.30).
This is with:
kernel-220.127.116.11-64.fc11.x86_64 + attached patch
Now to fixing compiz on r200...
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command
yum upgrade --enablerepo='*-updates-testing'
Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .
Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.
If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
All packages are up to date with respect to the updates repository and I've updated 'xorg*' from updates-testing. Bug is still present.
Tested with below package versions and bug still present:
With kernel-18.104.22.168-174.fc12.x86_64, this bug is apparently fixed. I had been using nomodeset (comment 6 above) to work around it, and that is no longer necessary.
I'll leave it to someone else to mark this bug as "closed".
I can confirm that the problem is solved in fc12.
Just upgraded to fc12.i386 and nomodeset is no longer required.
Thank you for letting us know.