Description of problem: When gnome-screensaver is fading the screen to black, it doesn't pay any attention to user input that should interrupt the fade and give me my normal interaction back. Version-Release number of selected component (if applicable): gnome-screensaver-2.26.1-2.fc11.i586 How reproducible: 100% Steps to Reproduce: 1. Run "gnome-screensaver-command -a" to get the fade started. 2. Watch the screen start to fade, wiggle the mouse, hit a key. 3. The screen still locks. Actual results: The screen fades to black and locks, but it takes a couple of seconds. Expected results: Either the screen should immediately drop into locked mode and present me with a password input (much less desirable, but okay), or it should restore me to normal interaction. Having it ignore my input, then fade to black, and require me to hit another key after waiting for the fade to complete, is impressively frustrating considering how minor it sounds.
I've had this happen automatically after the timeout, e.g. when watching a Flash video, and gss doesn't respond to input events but continues fading. For some reason, under this circumstance the fade is slower than usual.
Having the same problem. Exceptionally annoying in my case since I set my screensaver to a 1 or 2 minute activation for security reasons. It does seem that the fade is slower in these cases, as the previous poster states, but I was assuming that was my imagination. The problem seems to be more likely the longer the user has been logged-in. For example, if I restart my computer, the first time or first few times it starts to fade, I can recover by moving my mouse. However, eventually the problem starts and it does not go away until I restart my machine (perhaps logging out would accomplish the same goal, I do not know).
There are two fades. One is when fading slowly to indicate that the screen is about to lock. This one is interruptable. The other is the quicker fade out to a locked screen. This is not interruptable. If you are having problems with the first case please file a bug in GNOME bugzilla for this. I'm not able to reproduce this. The problem that is mentioned in the initial report sounds like the second case. And that is by design.
How does it sound like the second case?? Why would anyone want to "interrupt" the second case? How could anyone "interrupt" something that happens so quickly? How could you "interrupt" it in the first place if the change is already based upon the user taking an action?
It sounds like the second case because of step 1 in the original message.
Oh, I thought you were referring to an "unfading" fade from screensaver to lock screen, since you said that it was a "fade out to locked screen" which is not accurate because it is still fading to a screensaver. In any case, I think the original poster was simply trying to show how this bug can be reproduced (without waiting), not knowing that calling that command treats the fade differently. I could be wrong though.
Re: Comment #3 I have problem with the first case indeed, always reproducible in F11. Same as Nate, I set screensaver to 1 minute timeout at work, security reasons. The slow fade is uninterruptible, very annoying. It used to be interruptible in F10. So the solution is to open a bug in GNOME bugzilla. Sounds good.
Tim, Let us know the link if you make that post; I haven't gotten around to it yet myself.
Filed a bug at gnome bugzilla just now. http://bugzilla.gnome.org/show_bug.cgi?id=594082 Please send your support evidence there. Thanks.
FWIW, It doesnt happen to me anymore. Though i'm happy with that, it's still a bit strange because I dont know why it doesnt happen anymore.
Problem went away for me after this morning's Fedora 11 updates were installed: Sep 12 06:45:57 Updated: lohit-fonts-common-2.4.0-1.fc11.noarch Sep 12 06:45:58 Updated: gnome-python2-extras-2.25.3-7.fc11.i586 Sep 12 06:46:27 Updated: selinux-policy-3.6.12-82.fc11.noarch Sep 12 06:46:28 Installed: wine-fonts-1.1.29-1.fc11.noarch Sep 12 06:47:03 Updated: selinux-policy-targeted-3.6.12-82.fc11.noarch Sep 12 06:47:06 Updated: lohit-maithili-fonts-2.4.0-1.fc11.noarch Sep 12 06:47:09 Updated: lohit-telugu-fonts-2.4.0-1.fc11.noarch Sep 12 06:47:12 Updated: lohit-hindi-fonts-2.4.0-1.fc11.noarch Sep 12 06:47:15 Updated: lohit-kannada-fonts-2.4.0-1.fc11.noarch Sep 12 06:47:18 Updated: lohit-punjabi-fonts-2.4.0-1.fc11.noarch Sep 12 06:47:21 Updated: lohit-gujarati-fonts-2.4.0-1.fc11.noarch Sep 12 06:47:24 Updated: lohit-bengali-fonts-2.4.0-1.fc11.noarch Sep 12 06:47:27 Updated: lohit-tamil-fonts-2.4.0-1.fc11.noarch Sep 12 06:47:30 Updated: lohit-oriya-fonts-2.4.0-1.fc11.noarch Sep 12 06:47:51 Installed: wine-core-1.1.29-1.fc11.i586 Sep 12 06:47:57 Updated: xulrunner-1.9.1.3-1.fc11.i586 Sep 12 06:47:59 Updated: gnome-python2-gtkmozembed-2.25.3-7.fc11.i586 Sep 12 06:48:00 Updated: wine-cms-1.1.29-1.fc11.i586 Sep 12 06:48:01 Updated: wine-pulseaudio-1.1.29-1.fc11.i586 Sep 12 06:48:01 Updated: wine-ldap-1.1.29-1.fc11.i586 Sep 12 06:48:02 Updated: wine-capi-1.1.29-1.fc11.i586 Sep 12 06:48:03 Updated: wine-twain-1.1.29-1.fc11.i586 Sep 12 06:48:04 Updated: cloog-ppl-0.15.7-1.fc11.i586 Sep 12 06:48:06 Updated: postgresql-libs-8.3.8-1.fc11.i586 Sep 12 06:48:21 Updated: Miro-2.5.2-4.fc11.i586 Sep 12 06:48:47 Updated: yelp-2.26.0-7.fc11.i586 Sep 12 06:48:49 Updated: wine-nas-1.1.29-1.fc11.i586 Sep 12 06:48:50 Updated: wine-jack-1.1.29-1.fc11.i586 Sep 12 06:48:51 Updated: wine-esd-1.1.29-1.fc11.i586 Sep 12 06:48:52 Updated: gnome-python2-libegg-2.25.3-7.fc11.i586 Sep 12 06:48:53 Updated: gnome-python2-gtkhtml2-2.25.3-7.fc11.i586 Sep 12 06:48:54 Updated: alsa-plugins-pulseaudio-1.0.21-2.fc11.i586 Sep 12 06:48:55 Updated: wine-desktop-1.1.29-1.fc11.noarch Sep 12 06:48:57 Installed: wine-common-1.1.29-1.fc11.noarch Sep 12 06:49:02 Updated: firefox-3.5.3-1.fc11.i586 Sep 12 06:49:03 Updated: wine-1.1.29-1.fc11.i586 Sep 12 06:49:30 Erased: wine-tools
Me too, problem went away; still no idea why/how. Good anyway.