Bug 491244 - monitor is not put to sleep
Summary: monitor is not put to sleep
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 11
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-03-20 01:27 UTC by Björn Persson
Modified: 2018-04-11 07:45 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-25 22:42:07 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
X server log from live USB Rawhide (41.77 KB, text/plain)
2009-04-13 19:37 UTC, Björn Persson
no flags 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) (32.29 KB, text/plain)
2009-04-13 20:21 UTC, James
no flags Details
gnome-power-manager-2.26.0-1.fc11.x86_64 output after >2 minutes' wait (9.59 KB, text/plain)
2009-04-13 20:22 UTC, James
no flags Details
gnome-screensaver-2.26.0-2.fc11.x86_64 output after >2 minutes' wait (46.93 KB, text/plain)
2009-04-13 20:22 UTC, James
no flags Details

Description Björn Persson 2009-03-20 01:27:18 UTC
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 13:33:42 UTC
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 21:31:34 UTC
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 15:50:01 UTC
(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 19:37:17 UTC
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 20:19:41 UTC
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 20:21:26 UTC
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 20:22:10 UTC
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 20:22:48 UTC
Created attachment 339375 [details]
gnome-screensaver-2.26.0-2.fc11.x86_64 output after >2 minutes' wait

Comment 9 James 2009-04-14 09:20:39 UTC
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-16 00:45:00 UTC
(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 11:57:20 UTC
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 12:25:47 UTC
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 22:42:07 UTC
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-26 02:46:41 UTC
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 21:41:25 UTC
(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.


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