Bug 566351 - after interrupting the fading a few times, gnome-screensaver no longer locks the screen
after interrupting the fading a few times, gnome-screensaver no longer locks ...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: gnome-screensaver (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: jmccann
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-17 23:02 EST by Tim Taiwanese Liim
Modified: 2015-01-14 18:24 EST (History)
4 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Tim Taiwanese Liim 2010-02-17 23:02:39 EST
Description of problem:

    When g-ss detects idle timeout, it starts the screen saver, with
    about 10 sec of gamma fading, followed by the desired screen
    saver.  During the 10 sec gamma fading, the user may use kbd/mouse
    to interrupt the sequence, preventing the screen from being
    locked.  Repeat this interruption mutiple times, and g-ss no
    longer kicks in.

    This is actually a X server extension bug (Xext/sync.c);
    unfortunately g-ss was made to be guilty by association.  I opened
    bug566350 for this issue in xorg-x11-server just now; I'm keeping
    this bug here in g-ss as a pointer to the xorg bug.  Any sane
    people will surely look to g-ss for this issue, as it appears to
    be a g-ss bug, even though g-ss is actually behaving well.


Version-Release number of selected component (if applicable):
    F11: xorg-x11-server-Xorg-1.6.4-0.1.fc11.i586
    F12: xorg-x11-server-Xorg-1.7.4-6.fc12.i686
    F11: gnome-screensaver-2.26.1-3.fc11.i586
    F12: gnome-screensaver-2.28.3-1.fc12.i686

How reproducible:
    Elusive on F12; less elusive on F11.

    F11 + i386: a few times a day.
    F12 + i386: once a day or so.
    F12 + x64:  once in a few days. (I don't know why x64 makes any difference.)

Steps to Reproduce:
    1. change idle timeout to 1 minute, so it's easier to reproduce the issue.
       gnome-screensaver-preferences
            "Regard the computer as idle after"      1 minute
       gnome-power-preferences
            "Put display to sleep when inactive for" 1 minute
    2. wait 1 minute, till screen starts to fade (assume your screen supports
       gamma fading; my physical monitors all do, but my qemu vm does not.)
    3. hit a key to stop the fading.
    4. repeat step2,3 until screen no longer fades.  This may take 
              10-20 tries (on F11+i386), or 
              >100  tries (on F12+i386), or
              >?? (I lost count) tries (F12+x64)
  
Actual results:
    After many tries, screen no longer locks.

Expected results:
    Screen should always lock after idle timeout.

Additional info:
    1. See xorg bug566350 for further info.
    2. This bug seems to be a continuation of bug509660:
            bug509660 g-p-m fails to put display back to sleep after woken up 
                      with only a single keypress
Comment 1 Tim Taiwanese Liim 2010-02-25 21:25:53 EST
I found a more consistent way to reproduce this issue.  The bug is
in Xorg::Xext/sync.c, which is exposed by the behavior of g-p-m.

Steps to Reproduce:
    1. change idle timeout to 1 minute, so it's easier to reproduce the issue. 
       gnome-screensaver-preferences 
            "Regard the computer as idle after"      1 minute 
       gnome-power-preferences 
            "Put display to sleep when inactive for" 1 minute 
 
    2. kill gnome-power-manager, and start  a new one by 
        p='idle for|idle dim|idle dim|active for' 
        b=/usr/bin/gnome-power-manager 
        $b --verbose | egrep "$p" 

    3. In F11, hit a key, idle for 35 sec, hit a key, idle for
       65 sec, hit a key, idle for 65 sec, hit a key.  Wait 10
       minutes; g-ss will not kick in, thus issue reproduced.

       The delay is actually (in F11)
           for i in 30 60 60; do
               d=$i+5
               idle $d sec
               hit a key

       In F12, use
           for i in 10 20 40 60; do
               d=$i+5
               idle $d sec
               hit a key

       g-p-m should output something like (in F12)
             - resetting idle dim time to 10s
             - increasing idle dim time to 20s
             - increasing idle dim time to 40s
             - increasing idle dim time to 80s


       Here is some bash-ish mouse script (use mouse copy and paste to
       your terminal window) to help you get the right timing:
            t() {
                n=$1
                while [ $n -gt 0 ]; do
                    printf "$(date) $n   \r"
                    let n=$n-1
                    sleep 1
                done
                printf "\n"
            }
            t1() {
                for d in $*; do
                    let d1=$d+5
                    t $d1
                done
            }
            # F11
            t1 30 60 60
            # F12
            t1 10 20 40 60

The reason for those funny numbers (10 20 40 60 in F12):
    - g-p-m schedules two alarms with Xext/sync.c:IDLETIME counter:
      1. for DIM    event (idle for 
                           30, 60, 120, 240, ... sec in F11; 
                           10, 20,  40,  80, ... sec in F12)
      2. for NORMAL event (when user is active, kbd or mouse).

    - initially g-p-m uses 10 sec (in F12) for DIM alarm; if the user
      undims screen immediately (within 10 sec) after dimming, the
      DIM time is doubled.  When DIM time (120 sec in F11, 80 sec in 
      F12) is more than 60 sec (g-ss idle time), bug566350 in
      Xorg::Xext/sync.c kicks in, thus no more idle events are sent
      to g-ss or g-p-m.

    - in F11 we have 30 60 60; the first two (30 60) are for doubling
      DIM time; the last one (60) is for g-ss timeout.

    - in F12 we have 10 20 40 60; the first three (10 20 40) are for 
      doubling DIM time; the last one (60) is for g-ss timeout.


Source code for doubling dim timeout in g-p-m.
Note: the design and implementation of this code segment is sound; I
put it here only to show the doubling behavior.

    gpm_backlight_notify_system_idle_changed (gpm-backlight.c) 
        egg_debug ("we have just been idle for %lfs", elapsed);  
        /* The user immediatly undimmed the screen!  
         * We should double the timeout to avoid this happening again */  
        if (elapsed < 10) {  
                /* double the event time */  
                backlight->priv->idle_dim_timeout *= 2.0;  
                egg_debug ("increasing idle dim time to %is",
                            backlight->priv->idle_dim_timeout);  
                gpm_idle_set_timeout_dim (backlight->priv->idle,
                            backlight->priv->idle_dim_timeout);  
        }  
        /* We reset the dimming after 2 minutes of idle,  
         * as the user will have changed tasks */  
        if (elapsed > 2*60) {  
                /* reset back to our default dimming */  
                backlight->priv->idle_dim_timeout =  
                        gconf_client_get_int (backlight->priv->conf,  
                                   GPM_CONF_BACKLIGHT_IDLE_DIM_TIME, NULL);  
                egg_debug ("resetting idle dim time to %is", 
                                backlight->priv->idle_dim_timeout);  
                gpm_idle_set_timeout_dim (backlight->priv->idle, 
                                backlight->priv->idle_dim_timeout);  
        }
Comment 2 Tim Taiwanese Liim 2010-08-20 12:14:45 EDT
I'll close this bug due to lack of response from Adam (maintainer of
Xorg; speaking of role reversal, usually it's the developer who is
eager to close bugs; in this case, the originator sees no reason to
keep bug open for no good reason).  From what I experimented, I think
this bug has been fixed in F13.  Please reopen if you disagree.

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