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
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); }
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.