Bug 491244

Summary: monitor is not put to sleep
Product: [Fedora] Fedora Reporter: Björn Persson <bjorn>
Component: xorg-x11-serverAssignee: Adam Jackson <ajax>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 11CC: ajax, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-25 18:42:07 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
X server log from live USB Rawhide
none
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)
none
gnome-power-manager-2.26.0-1.fc11.x86_64 output after >2 minutes' wait
none
gnome-screensaver-2.26.0-2.fc11.x86_64 output after >2 minutes' wait none

Description Björn Persson 2009-03-19 21:27:18 EDT
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
Comment 1 James 2009-04-08 09:33:42 EDT
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.
Comment 2 Björn Persson 2009-04-08 17:31:34 EDT
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.
Comment 3 Matěj Cepl 2009-04-10 11:50:01 EDT
(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.
Comment 4 Björn Persson 2009-04-13 15:37:17 EDT
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.
Comment 5 James 2009-04-13 16:19:41 EDT
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.)
Comment 6 James 2009-04-13 16:21:26 EDT
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)
Comment 7 James 2009-04-13 16:22:10 EDT
Created attachment 339373 [details]
gnome-power-manager-2.26.0-1.fc11.x86_64 output after >2 minutes' wait
Comment 8 James 2009-04-13 16:22:48 EDT
Created attachment 339375 [details]
gnome-screensaver-2.26.0-2.fc11.x86_64 output after >2 minutes' wait
Comment 9 James 2009-04-14 05:20:39 EDT
Hmm. I find that DPMS *does* activate at the GDM login screen... could this be the same issue as Bug 489980?
Comment 10 Björn Persson 2009-04-15 20:45:00 EDT
(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.
Comment 11 Matěj Cepl 2009-04-16 07:57:20 EDT
OK, let's say that it is Xserver, but adding maintainer of g-p-m on CC list.
Comment 12 Bug Zapper 2009-06-09 08:25:47 EDT
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
Comment 13 Björn Persson 2009-07-25 18:42:07 EDT
I've finally managed to allocate a round tuit to re-testing this after I installed Fedora 11. The problem is gone.
Comment 14 Jeff Otterson 2009-07-25 22:46:41 EDT
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.
Comment 15 Björn Persson 2009-07-26 17:41:25 EDT
(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.