Test case: https://fedoraproject.org/wiki/QA:Testcase_intelvideo_dpms Hardware: Intel G35 Eizo FlexScan S2401W, 1920×1200 pixels, connected by DVI http://www.smolts.org/client/show_all/pub_4d74ea51-df80-4796-a3d1-2d97505593f6 Description of problem: The screensaver starts after one minute but the monitor is never put to sleep Version-Release number of selected component (if applicable): whatever is on rawhide-x86_64-20090312.0.iso How reproducible: five out of five attempts
I can confirm this behaviour with kernel-2.6.29.1-54.fc11.x86_64 xorg-x11-drv-intel-2.6.99.902-2.fc11.x86_64 gnome-screensaver-2.26.0-1.fc11.x86_64 gnome-power-manager-2.26.0-1.fc11.x86_64 xorg-x11-server-Xorg-1.6.0-17.fc11.x86_64 on my notebook with an Intel X3100 chip. Björn, please increase the severity on this bug as it eats up battery power by both keeping the display on, and allowing the screensaver to continue to run.
If you want to keep the screensaver from consuming power then I suggest choosing a blank screensaver, and when running on battery you should probably suspend the whole computer when you're not using it, which should turn the display off as well, so I think low severity is right. Now, if suspending doesn't work, that would motivate at least medium severity, but that would be a different bug.
(In reply to comment #1) > Björn, please increase the severity on > this bug as it eats up battery power by both keeping the display on, and > allowing the screensaver to continue to run. Just standing behind Björn: this argument doesn't make any sense ... saying us that the bug is severe, because there is a bug there, doesn't make it any more important than other hundreds of bugs with have in bugzilla. Please attach your X server config file (/etc/X11/xorg.conf, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 339366 [details] X server log from live USB Rawhide I've gone through the test case again, with the live system from the Intel video test day, and saved this log. There is no xorg.conf. James, will you submit your log? I assume it may be helpful to have that as well.
I'm not sure it's an intel driver bug, since I see the same behaviour on a notebook with an ATI chip. It might be gnome-power-manager. Nevertheless, here's my X.org log, plus output from g-p-m and gnome-screensaver. (I set the screensaver to trigger after 1 minute, screen off 1 minute after that, and waited a few minutes.)
Created attachment 339372 [details] X.org log (server 1.6.0-19 intel driver 2.6.99.902-2, g-ss 2.26.0-2, g-p-m 2.26.0-1)
Created attachment 339373 [details] gnome-power-manager-2.26.0-1.fc11.x86_64 output after >2 minutes' wait
Created attachment 339375 [details] gnome-screensaver-2.26.0-2.fc11.x86_64 output after >2 minutes' wait
Hmm. I find that DPMS *does* activate at the GDM login screen... could this be the same issue as Bug 489980?
(In reply to comment #9) > Hmm. I find that DPMS *does* activate at the GDM login screen... How long did that take? Nothing happened for over 15 minutes for me. > could this be the same issue as Bug 489980? "xset dpms force off" does nothing for me (just returns zero), so I suppose it's not just gnome-power-manager in my case.
OK, let's say that it is Xserver, but adding maintainer of g-p-m on CC list.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I've finally managed to allocate a round tuit to re-testing this after I installed Fedora 11. The problem is gone.
Folks, This is absolutely NOT FIXED. The screensaver and power management, when used together, will turn off the display exactly once. The second time, the display never turns off.
(In reply to comment #14) > The screensaver and power management, when used together, will turn off the > display exactly once. The second time, the display never turns off. That's not what I saw with the test day snapshot. The monitor didn't go to sleep even once. "xset dpms force off" didn't work either then. Now it does, and not just once, so that bug appears to be fixed. The problem you describe is probably a different bug, so I think you should open a separate bug report.