Bug 508558 - xset dpms force off stopped working - no blanking
xset dpms force off stopped working - no blanking
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
  Show dependency treegraph
Reported: 2009-06-28 11:14 EDT by jonathan baron
Modified: 2010-02-08 20:21 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-02-08 20:21:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch fixing DPMS issues (685 bytes, patch)
2009-10-14 01:12 EDT, Philippe Troin
no flags Details | Diff

  None (edit)
Description jonathan baron 2009-06-28 11:14:11 EDT
Description of problem:
xset dpms force off does nothing

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. type "xset dpms force off" in terminal
Actual results:
nothing happens

Expected results:
screen blanks (and goes into low power mode)

Additional info:
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)
Comment 1 jonathan baron 2009-06-29 06:24:29 EDT
The bug is a result of the new kernel.  If I reboot using


everything works.

The new kernel that causes the problem is

Comment 2 Juhani Jaakola 2009-07-05 14:15:48 EDT
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-, so the bug is not only on x86_64.
Comment 3 Juhani Jaakola 2009-07-05 16:12:38 EDT
The command "xset dmps force off" works with kernel- but not with kernel- 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.
Comment 4 Juhani Jaakola 2009-07-06 04:43:21 EDT
The command "xset dmps force off" works with kernel- 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-* does not work. Please note that with Thinkpad R50p (see my posts yesterday) I used the radeon driver, not the fglrx driver.
Comment 5 Bob Glickstein 2009-07-13 14:45:03 EDT
I'm seeing this too with kernel on my old Dell XPS workstation, using the radeon driver.
Comment 6 Bob Glickstein 2009-07-14 09:52:35 EDT
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).
Comment 7 jonathan baron 2009-07-15 03:15:41 EDT
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."
Comment 8 dann 2009-07-24 10:19:23 EDT
When using kernel version
dpms blanking works fine, it does not work when booting
kernel- (or the .5 kernel)
Comment 9 Ian Collier 2009-08-18 08:12:17 EDT
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)
Comment 10 Nicholas Miell 2009-08-25 03:20:11 EDT

ATI Technologies Inc Radeon R200 QH [Radeon 8500] (rev 80)

Works with nomodeset, doesn't work without.
Comment 11 dekellum 2009-09-19 17:51:23 EDT

ATI Technologies Inc RV380 [Radeon X600 (PCIE)] rev 0

"xset dmps force off" works with nomodeset, doesn't work without.
Comment 12 Philippe Troin 2009-10-14 01:12:12 EDT
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- + attached patch

Now to fixing compiz on r200...
Comment 13 Matěj Cepl 2009-11-05 13:33:16 EST
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.]
Comment 14 Ian Collier 2009-11-06 08:25:06 EST
All packages are up to date with respect to the updates repository and I've updated 'xorg*' from updates-testing.  Bug is still present.

Comment 15 Kenneth Soerensen 2009-11-08 05:04:34 EST
Tested with below package versions and bug still present:

Comment 16 jonathan baron 2010-01-11 05:10:41 EST
With kernel-, 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".
Comment 17 Kenneth Soerensen 2010-02-08 14:33:26 EST
I can confirm that the problem is solved in fc12.

Just upgraded to fc12.i386 and nomodeset is no longer required.

Comment 18 Matěj Cepl 2010-02-08 20:17:55 EST
Thank you for letting us know.

Note You need to log in before you can comment on or make changes to this bug.