Bug 566351
| Summary: | after interrupting the fading a few times, gnome-screensaver no longer locks the screen | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tim Taiwanese Liim <tim.liim> |
| Component: | gnome-screensaver | Assignee: | jmccann |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 12 | CC: | cschalle, james, jmccann, rstrode |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-08-20 16:14:45 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. |
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