Bug 508886

I have the same issue in F11 with fresh installation; it used to work
fine in F10.  This bug
    bug509660 g-p-m fails to put display back to sleep after 
              woken up with only a single keypress
described the issue more precisely.  Also I realized that the display
sleep (turn back light off) is controlled by gnome-power-manager, not
gnome-screensaver So bug509660 is the right place for this issue.

I would suggest we leave this bug open with g-ssaver as the Component
field though; any sane people (like me :-) would look to gnome-ssaver
for this display sleep issue, even though g-ssaver is the innocent
by-stander.  It'll be helpful to leave this bug open with a pointer to
bug509660 so others can easily find the right bug and the right
component, gnome-power-manager.

Workaround: 
  - after each display sleep, kill and restart g-p-m.  It appears that
    g-p-m works fine on first display sleep, so restart g-p-m ensures
    you have the "first display sleep."
  - this trick worked on 2 out of 3 laptops I tried.  Anyone knows a 
    sure-fire workaround please let us know.

See also https://bugzilla.redhat.com/show_bug.cgi?id=509660#c3

Another less painful workaround.
  - Inside X, use the 'xset' command, like this: 
      xset dpms 300 300 300         # in seconds 
           first value given is for the "standby" mode,  
           the second is for the "suspend" mode, and  
           the third is for the "off" mode. 
    See "man xset" for details.  
    When I tried "xset dpms 10 10 10", the display actually
    slept after 10 sec, BUT comes back sometime later by 
    itself!  I have to use "xset dpms 10 10 0" to make it 
    happy.  Anyone knows why?

  - this is not good for video viewing, although good for
    a web server.

  - this "xset dpms" tricks again worked on 2 out my 3 laptops.
    All 3 used to work fine in F10.

  - For the stubborn one, I switch to tty2 (Ctrl-Alt-F2),
        echo -e "\033[14;10]"       # screen sleep in 10 minutes 
    See man "console_codes", search for "power".
       ESC [ 14 ; n ]      Set the VESA powerdown interval in minutes.

    This did the trick, turn off the backlight.  It's not
    perfect though; I tried to set it to 1 minute:
        echo -e "\033[14;1]"
    Still the sleep kicked in after 10 minutes.  
    Oh well.  At least my laptop backlight is not burning overnight.

Is this still an issue?  I think it was fixed a few weeks ago,
although I cannot pinpoint when.  See also bug509660 Comment #11,
bug509660 Comment #12.  Should we close this bug?

Can we close this bug?  g-p-m is working fine now.

Not for me it isn't! Problem is still present on my F12 machine.

Brian,
When you say the problem still present on your F12, do you mean the
scenario as described in Comment #0 by Rick?
  - g-ss kicks in properly
  - but g-p-m does not put display to sleep after x minutes.

Tim,

That is exactly what I meant - but after seeing your comment, I can no longer reproduce the problem! I'll post another comment if I am able to break it again, but so far it looks like it is in fact working for me now.

It has stopped working again. I had rebooted shortly before writing my previous comment, and it worked for a while, then stopped working. I've noticed that pattern before, by the way.

I find it fails to sleep the first time (in a session) and the works thereafter.

Re: Comment #9
> it worked for a while, then stopped working.
Brian,
By "stopped working" do you mean the same as before?
  - g-ss kicks in properly
  - but g-p-m does not put display to sleep after x minutes.
g-ss (gnome-screensaver) and g-p-m (gnome-power-manager) are two
separate entities, so we need to figure out which one to look into.
If g-ss works properly but g-p-m fails, we should write a different
bug for g-p-m, not keeping it on this g-ss bug.


Re: Comment #10
> it fails to sleep the first time (in a session)
James,
do you mean the same as well?
  - g-ss kicks in properly
  - but g-p-m does not put display to sleep after x minutes.
Because there are two entities involved, we need to be very clear as
to what you meant by "fails to sleep."  If it's a g-p-m problem we
should open a new bug for g-p-m.

I wrote a related bug a few days; just FYI.
    bug566351 after interrupting the fading a few times, 
              gnome-screensaver no longer locks the screen

Suddenly my F12 x64 started doing this too :-), although just once.
  - g-ss kicks in properly
  - but g-p-m does not put display to sleep after x minutes.
It was all fine before today.  Now I know what Brian and James were
talking about.

I did have strace on g-p-m at that time.  In the good runs when g-p-m
blanked the screen propely (put display to sleep), X server
(/usr/bin/Xorg) sent a msg like this
  23:30:56.230577 read(3,  ..., 4096) = 32
   | 00000  01 01 4b 02 00 00 00 00  6a 00 e0 04 00 00 00 00  ..K..... j....... |
   | 00010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........ |

In bad run when I expect g-p-m to blank screen, no such msg comes from
X server (I waited 10 minutes beyond the expected time).  So either X
server didn't to its job to send whatever msg to g-p-m, or g-p-m did
not register with X server properly.  We "just" need to figure out
which case it is.

Tim,

Screensaver blanks the screen, but the monitor never goes into powersave mode.

This bug *is* filed against g-p-m.

I've been playing with it some more, rebooting seems to make it work for a while, then it will stop working until the next reboot.

(In reply to comment #11)
> James,
> do you mean the same as well?
>   - g-ss kicks in properly
>   - but g-p-m does not put display to sleep after x minutes.

I'll revise my earlier comment. On my machine:

 - Following the FIRST idle-timeout after login or resume-from-suspend,
   the screen-saver starts, but the screen is not switched off after the
   times set.

 - After unlocking, on subsequent idle-timeouts, behaviour is as it should be:
   the screen-saver starts, and the screen turns off one minute later, as set.

Re: Comment #13
> This bug *is* filed against g-p-m.
Yes, you are definitely right; the component field is g-p-m.  For some
reason (probably the subject of this bug
     bug508886 gnome-screensaver does not put display to sleep.)
I kept on thinking this bug was for g-ss.  From bug history it was
filed against g-ss to begin with, then changed to g-p-m later.

Re: Comment #13
> Screensaver blanks the screen, but the monitor never goes into
> powersave mode.
Brian,
Now I understand the symptom.  I believe it's caused by
    bug566350 Xext/sync.c IDLETIME counter sometimes fails to fire 
              when wrapped around

Here is my reasoning.
 - g-p-m has 3 major events: (in src/gpm-backlight.c::idle_changed_cb)
        #1 GPM_IDLE_MODE_DIM 
        #2 GPM_IDLE_MODE_BLANK 
        #3 GPM_IDLE_MODE_NORMAL 

  - when the session is idle long enough (see bug566350 Comment #3), 
    #1 (DIM) is invoked, which schedules a local timer (eg. 60 sec)
    for #2 (BLANK).  When the user becomes active (key or mouse
    event), #3 (NORMAL) is invoked.  If #3 NORMAL comes before timer
    of #2 BLANK, the timer for #2 is cancelled.  #2 BLANK is where the
    screen is put to sleep (DPMS off).

  - g-p-m registers with Xorg (X server) for alarms of #1 DIM and #3
    NORMAL.  If X server does not send alarm msg (bug566350) to g-p-m
    for #1 DIM, g-p-m will not schedule local timer for #2 BLANK, so
    screen will not be put to sleep.

To verify my conjecture:
  - kill g-p-m
  - start a new instance of g-p-m:
          /usr/bin/gnome-power-manager --verbose
  - when g-p-m receives idle alarm from X server, g-p-m prints this:

        TI:23:40:45     TH:0xbb4080     FI:gpm-idle.c   
                        FN:gpm_idle_idletime_alarm_expired_cb,379
         - idletime alarm: 1
        ...
        TI:23:40:45     TH:0xbb4080     FI:gpm-idle.c   
                        FN:gpm_idle_evaluate,275
         - setting up blank callback for 60s
    This line "setting up blank callback for 60s" is where the local
    timer for #2 is scheduled.

  - If you see the line "FN:gpm_idle_idletime_alarm_expired_cb" but 
    not the line "setting up blank callback for 60s", then the problem
    is with g-p-m, because #1 DIM should schedule local timer for #2 
    BLANK.

  - If you don't see the line "FN:gpm_idle_idletime_alarm_expired_cb"
    when you expect to, the problem is with X server bug566350.

  - I believe the problem is with X server, not with g-p-m.

Please let me know if you need further info.

Re: Comment #14
James,
Could you try the following?
  - kill g-p-m
  - start a new instance of g-p-m in a terminal:
          /usr/bin/gnome-power-manager --verbose

  - then suspend your system; then resume.

  - check if g-p-m misses its FIRST idle-timeout as it
    used to on your system.

  - if so, check the presence of this output line from g-p-m:
        FN:gpm_idle_idletime_alarm_expired_cb
    If you don't see it, the problem is with X server.
    If you see it, we need to debug g-p-m a bit further.

Please let me know how it goes.

Tim, I've got g-p-m running in a terminal with the --verbose flag. Restarting g-p-m made it start working again; I won't be able to answer your question until it stops working. It *always* stops working after a while, so it's just a matter of waiting. I'll let you know as soon as I have an answer.

It took a while for it to stop working this time, but it finally did. Here's the g-p-m --verbose output:

TI:21:36:09	TH:0x8d82880	FI:gpm-idle.c	FN:gpm_idle_idletime_alarm_expired_cb,379
 - idletime alarm: 1
TI:21:36:09	TH:0x8d82880	FI:gpm-idle.c	FN:gpm_idle_evaluate,213
 - session_idle=0, session_inhibited=0, x_idle=1
TI:21:36:09	TH:0x8d82880	FI:gpm-idle.c	FN:gpm_idle_evaluate,267
 - normal to dim
TI:21:36:09	TH:0x8d82880	FI:gpm-idle.c	FN:gpm_idle_set_mode,133
 - Doing a state transition: dim
TI:21:36:09	TH:0x8d82880	FI:gpm-backlight.c	FN:gpm_backlight_notify_system_idle_changed,527
 - we were active for 50.525552s
TI:21:36:09	TH:0x8d82880	FI:gpm-backlight.c	FN:gpm_backlight_notify_system_idle_changed,530
 - changing powersave idle status to 1
TI:21:36:09	TH:0x8d82880	FI:gpm-backlight.c	FN:gpm_backlight_brightness_evaluate_and_set,285
 - no dimming hardware
TI:21:36:09	TH:0x8d82880	FI:gpm-dpms.c	FN:gpm_dpms_x11_set_mode,158
 - DPMS not enabled
TI:21:36:09	TH:0x8d82880	FI:gpm-backlight.c	FN:idle_changed_cb,580
 - failed to turn on DPMS: DPMS is not enabled
TI:21:36:09	TH:0x8d82880	FI:gpm-idle.c	FN:gpm_idle_evaluate,275
 - setting up blank callback for 300s
TI:21:39:59	TH:0x8d82880	FI:gpm-session.c	FN:gpm_session_presence_status_changed_cb,133
 - emitting idle-changed : (1)
TI:21:39:59	TH:0x8d82880	FI:gpm-idle.c	FN:gpm_idle_session_idle_changed_cb,357
 - Received gnome session idle changed: 1
TI:21:39:59	TH:0x8d82880	FI:gpm-idle.c	FN:gpm_idle_evaluate,213
 - session_idle=1, session_inhibited=0, x_idle=1
TI:21:41:10	TH:0x8d82880	FI:gpm-idle.c	FN:gpm_idle_set_mode,133
 - Doing a state transition: blank
TI:21:41:10	TH:0x8d82880	FI:gpm-backlight.c	FN:gpm_backlight_notify_system_idle_changed,496
 - state not changed
TI:21:41:10	TH:0x8d82880	FI:gpm-backlight.c	FN:gpm_backlight_brightness_evaluate_and_set,285
 - no dimming hardware
TI:21:41:10	TH:0x8d82880	FI:gpm-dpms.c	FN:gpm_dpms_x11_set_mode,158
 - DPMS not enabled
TI:21:41:10	TH:0x8d82880	FI:gpm-backlight.c	FN:idle_changed_cb,611
 - failed to change DPMS: DPMS is not enabled

Brian,
Thank you for your patience!  So your result in Comment #19 proved
that my conjecture ("it's related to bug566350") in Comment #16 was
wrong.  Specifically, these lines
    TI:21:36:09 TH:0x8d82880 FI:gpm-idle.c
    FN:gpm_idle_idletime_alarm_expired_cb,379
     - idletime alarm: 1
showed that Xorg did send idle msg to g-p-m for #1 GPM_IDLE_MODE_DIM.
These lines
    TI:21:36:09 TH:0x8d82880 FI:gpm-idle.c FN:gpm_idle_evaluate,275
     - setting up blank callback for 300s
proved that #1 DIM did schedule local timer for #2 BLANK, which did
fire at right time (300 sec later) at
    TI:21:41:10 TH:0x8d82880 FI:gpm-idle.c FN:gpm_idle_set_mode,133
     - Doing a state transition: blank
So it's not bug566350.

But then note these lines from your Comment #19:
    TI:21:41:10 TH:0x8d82880 FI:gpm-dpms.c FN:gpm_dpms_x11_set_mode,158
     - DPMS not enabled
    TI:21:41:10 TH:0x8d82880 FI:gpm-backlight.c FN:idle_changed_cb,611
     - failed to change DPMS: DPMS is not enabled    
On my machine when g-p-m is working fine, in the corresponding spot I
have
    TI:00:08:34 TH:0x1faa080 FI:gpm-manager.c 
    FN:gpm_manager_dpms_mode_changed_cb,1718
     - DPMS mode changed: 3
    TI:00:08:34 TH:0x1faa080 FI:gpm-manager.c 
    FN:gpm_manager_dpms_mode_changed_cb,1727
     - dpms off
    TI:00:08:34 TH:0x1faa080 FI:gpm-screensaver.c 
    FN:gpm_screensaver_add_throttle,233
     - adding throttle reason: 'Display DPMS activated': id 162320677
That is, when the issue occured, your g-p-m said "DPMS not enabled",
"failed to change DPMS: DPMS is not enabled".  In good case g-p-m
happily said "DPMS mode changed: 3", "dpms off".


Brian,
Could you re-run g-p-m --verbose, and post the lines after
    TI:21:41:10 TH:0x8d82880 FI:gpm-idle.c FN:gpm_idle_set_mode,133
     - Doing a state transition: blank
in a *good* run (when g-p-m puts screen to sleep properly)?  So we can
see what the msg "DPMS not enabled" is about.


FYI: Xorg (the X server) has several extensions, two of which are:
   "SYNC" is used by g-p-m and g-ss (via g-s; g-ss=gnome-screensaver, 
          g-s=gnome-session) to provide idle alarm.
   "DPMS" is used by g-p-m to turn on/off screen backlight.

As requested:

TI:23:35:23	TH:0x98f0880	FI:gpm-idle.c	FN:gpm_idle_set_mode,133
 - Doing a state transition: blank
TI:23:35:23	TH:0x98f0880	FI:gpm-backlight.c	FN:gpm_backlight_notify_system_idle_changed,496
 - state not changed
TI:23:35:23	TH:0x98f0880	FI:gpm-backlight.c	FN:gpm_backlight_brightness_evaluate_and_set,285
 - no dimming hardware
TI:23:35:27	TH:0x98f0880	FI:gpm-manager.c	FN:gpm_manager_dpms_mode_changed_cb,1718
 - DPMS mode changed: 3
TI:23:35:27	TH:0x98f0880	FI:gpm-manager.c	FN:gpm_manager_dpms_mode_changed_cb,1727
 - dpms off
TI:23:35:27	TH:0x98f0880	FI:gpm-screensaver.c	FN:gpm_screensaver_add_throttle,233
 - adding throttle reason: 'Display DPMS activated': id 96791119

So Brian proved that DPMS is the issue for Comment #6.  It appeared
that DPMS moved from good (#2) to bad (#1) after some time.

Code around #1 "DPMS not enabled":
        DPMSInfo (GDK_DISPLAY (), &current_state, &current_enabled);
        if (!current_enabled) { 
                egg_debug ("DPMS not enabled"); 
                return FALSE;
That is, g-p-m invokes DPMSInfo (see #3) to query DPMS extension in
Xorg to see if DPMS is enabled.  In bad cases, DPMS is disabled.  By
whom?  When?  Under what condition?  We don't have the answer yet.
But I happened to see a function named DPMSDisable() in #3; who used
it?  g-p-m does not use DPMSDisable() at all (nowhere in the source
tree).


Brian,
Are you comfortable using gdb?  If so, we may be able to get more info
out of Xorg.  I could not reproduce this "DPMS not enabled" issue
reliably, so I cannot try it myself.  Or, if you know how to make Xorg
more verbose, maybe we can find out who disabled DPMS by looking at
the log file.

For now, we nailed down the key signature of this issue in #1, "DPMS
not enabled".


#1 Bad run (from Comment #19):
    TI:21:41:10 TH:0x8d82880 FI:gpm-dpms.c FN:gpm_dpms_x11_set_mode,158
     - DPMS not enabled
    TI:21:41:10 TH:0x8d82880 FI:gpm-backlight.c FN:idle_changed_cb,611
     - failed to change DPMS: DPMS is not enabled    

#2 Good run (from Comment #21):
    TI:23:35:27 TH:0x98f0880 FI:gpm-manager.c
    FN:gpm_manager_dpms_mode_changed_cb,1718
     - DPMS mode changed: 3
    TI:23:35:27 TH:0x98f0880 FI:gpm-manager.c
    FN:gpm_manager_dpms_mode_changed_cb,1727
     - dpms off
    TI:23:35:27 TH:0x98f0880 FI:gpm-screensaver.c
    FN:gpm_screensaver_add_throttle,233
     - adding throttle reason: 'Display DPMS activated': id 96791119

#3 API to DPMS extension in X server:
    /usr/include/X11/extensions/dpms.h
        extern Status DPMSInfo(Display *, CARD16 *, BOOL *); 
        extern Status DPMSEnable(Display *);
        extern Status DPMSDisable(Display *);

Re: Comment #22
> Are you comfortable using gdb?
I found two less painful ways (than gdb X server) to debug this issue.

#1 use xset to enable/disable DPMS:
   - "xset -dpms" to disable DPMS in X server
   - "xset +dpms" to  enable DPMS in X server
#2 compile Xorg from source rpm (it's not too painful with Fedora),
   and add debug msg to see when DPMS is disabled.

I suggest we try #1 first since it involves less pain.  So could you
use "xset -dpms" to see if the same symptom shows up.  If so, (here is
the leap of faith), we can write a shell script to intercept xset:
  - "su -" to become root
  - create a file xset.sh, with this content:
        #!/bin/bash
        log=/tmp/xset.log
        echo "$(date) xset" "$@" >> $log
        exec /usr/bin/xset.bin "$@"
  - cp /usr/bin/xset /usr/bin/xset.bin
    chcon system_u:object_r:bin_t:s0 /usr/bin/xset.bin
    cp xset.sh /usr/bin/xset
The intention is to create a middleman "xset.sh" to log any invokation
to xset, which is now renamed to be xset.bin.

If we are lucky, if some processes actually invokes "xset -dpms" to
turn off dpms, then we can enhance the middleman to log the caller as
well.

On the other hand, if the culprit is smart enough (not using "xset
-dpms"), we can try #2.

I have used gdb only a tiny bit quite a few years ago, but I do have a lot of experience with debuggers. Compiling Xorg from source rpm should also not be a problem for me.

I'm at work at the moment, so I can't try any of this yet, but your comment about something turning off DPMS reminded me that the most recent failure happened right after I had been watching videos. I'm not sure if I was using VLC or xine (possibly both). I suspect the video player may have turned off DPMS and failed to turn it on again.

I'll do some testing with your script and VLC/xine and let you know what happens.

Brian,
Now that you mentioned vlc and xine, I also tried vlc, and like any
good video player, it does send DPMSDisable to Xorg when playback
starts, and DPMSEnable when stops normally.  When I "pkill -9 vlc",
which leaves vlc no chance to send DPMSEnable; indeed g-p-m says "DPMS
not enabled" thereafter.  But in this case I believe that
  - vlc is not at fault (nothing you can do when hit by SIGKILL); 
  - g-p-m is not at fault (DPMS is disabled; what can g-p-m do?); 
  - Xorg is not at fault (someone told me DPMSdisable and never comes
    back).
  - user has to do "xset +dpms" to rectify this situation.

vlc issued DPMSDisable/Enable directly, not thru xset, so my previous
xset.sh middleman cannot catch vlc.  I think we need to go for Comment
#23, item #2; I'll send you the procedure a bit later.

A short notes on gdb:
  - This attaches to Xorg, the X server (as root user):
        gdb - $(pgrep Xorg) 
    But be very careful when gdb X server; if you do this in X window,
    when hitting a break point, gdb would stuck because it cannot send
    output to X server, who is not responding.  I usually ssh from
    another machine, so when gdb stop Xorg, I wouldn't get stuck.

  - some gdb commands:
    q                   -- quit
    b file.c:123        -- break point
    i b                 -- show break points
    d 1                 -- delete breakpoint 1
    c                   -- continue
    p <variable>        -- print value of variable
    r <args>            -- run program with args
    h                   -- help

  - eg. to debug g-p-m from start:
    gdb /usr/bin/gnome-power-manager
    r --verbose

Created attachment 400924 [details]
patch for debugging DPMS extension in Xorg

For Comment #23, item #2.

- To compile Xorg from source rpm:
  1. As regular user (ie. not root user), run
        yumdownloader --source xorg-x11-server-Xorg
     which download the source file, eg. 
        xorg-x11-server-1.7.5-2.fc12.src.rpm
  2. Run
        p=xorg-x11-server-1.7.5-2.fc12.src.rpm
        rpm -i $p
     this creates rpmbuild/.
  3. Do this
        cd ~/rpmbuild/
        time rpmbuild -bb SPECS/xorg-x11-server.spec
  4. If you don't have rpmbuild: login as root user,
        yum provides */rpmbuild
     which say things like
        rpm-build-4.7.2-1.fc12.x86_64
     so we do
        yum install -y rpm-build
     Try Step 3 again.
  5. The first time you do step 3, you probably will encounter
     error msgs like
	git-core is needed by xorg-x11-server-1.7.5-2.fc12.src
     so 
        s=SPECS/xorg-x11-server.spec
        a=$(rpmbuild -bb $s 2>&1 | tail -n +2 | sed -r 's/( is |>=).*//')
        echo $a > /tmp/t
     Login as root user
        a=$(cat /tmp/t)
        yum install -y $a
     Then go back to step 3.
  6. The binaries are in
        ~/rpmbuild/BUILD/xorg-server-*
     The rpm files are in
        ~/rpmbuild/RPMS/

- To recompile Xorg after modifying files
  1. As the regular user, do
        cd ~/rpmbuild/BUILD/xorg-server-*

  2. Edit files as needed.  (See **1 below for what files
     to edit for this bug.)

  3. Build with debug info on:
        make clean      # if clean build is desired
        make -j 2 V=1 CFLAGS=-g

- To copy compiled executables to system location:

  1. As root user, do these (use mouse copy and paste); 
     be sure to plug in the right <your user id>
        do=/home/<your user id>/rpmbuild/BUILD/xorg-server-1.7.5
        # do = directory for object file
        ts=$(date '+%H.%M.%S')  # timestamp

        i=$do/hw/xfree86/dixmods/extmod/.libs/libextmod.so
        j=/usr/lib64/xorg/modules/extensions/libextmod.so
        c=system_u:object_r:lib_t:s0
        mv $j $j.$ts
        /bin/cp $i $j
        chcon   $c $j
        ls -l $j*; ls -lZ $j*

        i=$do/hw/xfree86/Xorg
        j=/usr/bin/Xorg
        c=system_u:object_r:xserver_exec_t:s0
        mv $j $j.$ts
        /bin/cp $i $j
        chcon   $c $j
        ls -l $j*; ls -lZ $j*

  2. logout of gnome and login, so the new Xorg is used.

- Where is the DPMS debug output:
  1. login using GUI as usual.  As root user, do
        f=/var/log/gdm/:0.log
        tail -f $f | grep -i DPMS
      Now you know what the DPMS extension in X server is doing.

**1 The files to edit for debugging DPMS extension in Xorg:
        Xext/dpms.c
        hw/dmx/dmxdpms.c
        hw/xfree86/common/xf86DPMS.c
    You can apply the patch file by
        do=/home/<your user id>/rpmbuild/BUILD/xorg-server-1.7.5
        cd $do
        patch -p1 < bug.508886.comment.26.patch
    The tgz file
        bug.508886.comment.26.patch.tgz
    has the patch and the before/after files.

Re: Comment #10, Comment #14
James,
Recently I happened to install F12 on a slow 700MHz laptop, and lo and
behold, I see the issue you reported.  Do you have a slow machine too?

I filed a new bug just now.
    bug575590 no display sleep upon 1st idle timeout on slow machines

(In reply to comment #27)
> Re: Comment #10, Comment #14
> James,
> Recently I happened to install F12 on a slow 700MHz laptop, and lo and
> behold, I see the issue you reported.  Do you have a slow machine too?
> 
> I filed a new bug just now.
>     bug575590 no display sleep upon 1st idle timeout on slow machines    

Tim, sorry I've not been able to get back to you on your suggested tests so far. Hopefully soon I'll be able to sit down and get you something.

I see this on two machines: one of them has ATI graphics and a 2.8 GHz Pentium 4 processor. The other has Intel graphics and an Intel Core 2 Duo T8100 processor (800-2101 MHz).

James,
Your machines are definitely much faster than my 700MHz lappy; so even
though the symptoms are the same in your Comment #14 and my bug575590,
they may still come from different underlying causes.  Is it posible
that you do this measurement?
  - at password prompt, after entering password,
    start a stop watch, and hit enter at the same time.
  - stop the stop watch when gnome seems to finish its initialization
    (panel loaded, icon on panels shows up, icon on desktop show up,
    etc.) and no more movement on the gnome desktop.
Here is my measurement
  - on 700MHz lappy: 30 sec; then g-p-m failed to put display to sleep.
  - on 2.5GHz: 8 sec, and g-p-m worked fine (put display to sleep).
  - on the same 2.5GHz, but intentionally slowed down (set CPU to 800MHz,
    ran 20 cpu huggers (while (1) i++; ):
    45 sec; g-p-m failed to put display to sleep.
I am still suspecting that your observation somehow :-) could still be
part of bug575590.

By any chance do you do C programming?  If so we can debug this issue
in further detail.  Cheers.

(In reply to comment #29)
> James,

--> Response in bug 575590.

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Tim,

I've been keeping a close eye on this for the last several weeks, and indeed the problem only occurs when a video player has crashed or been killed. The original problem seems to be fixed for me.

I agree it's not really the fault of the video player, or g-p-m, or Xorg... but there's gotta be a better way. I can think of a few ways, probably the simplest is to create an API function that allows the caller to specify an amount of time for which to disable DPMS. When that time has elapsed, DPMS is automatically re-enabled. The caller would simply call the function periodically at an interval that is smaller than the time passed to the function. If the caller crashes or is killed, DPMS will start working again when the disable time expires.

Should I file a new bug report as a feature request? I suspect this is a different issue than what this bug report was about.

Brian,
> ... create an API function that allows the caller to specify an
> amount of time for which to disable DPMS ...
Agree, a new API to disable DPMS with timeout is the simplest solution
to me as well.  But maybe folks at Xorg have better idea; let's pose
the issue to them and see if they have better solution.

> Should I file a new bug report as a feature request?
Yes, please file a new bug as feature request, and post the bug #
here, so those who are interested know where to follow up.  The
component for X server DPMS extension is
    xorg-x11-server-Xorg

> I suspect this is a different issue than what this bug report was
> about.
Yes, this is definitely different from this bug508886, which I also
observed (Comment #1) and witnessed it fixed (Comment #4).

I believe this bug can be closed now, since all issues are either
fixed or tracked in other bugs.

- Comment #1 original issue was fixed (Comment #4).

- Comment #6 is related to video players (vlc, xine) crashes (eg. 
  kill -9), thus could not re-enable DPMS.  Confirmed in Comment #32
  and will be tracked in a new RFE bug.

- Comment #10 g-p-m does not sleep screen after first idle timeout
  => Comment #27, spawns bug575590
     bug575590 no display sleep upon 1st idle timeout on slow machines

Agreed, closing.