Gnome Screensaver does not activate reliably

Thanks for your report, that works fine for me, which video driver are you using? does ti works fine with another new user created on your system?

Video driver is fglrx. I switched to that because the Ubuntu supplied driver didn't work properly on either Gutsy or Hardy. I'm reluctant to create another user as I suspect I won't be able to properly delete it later (this happened on Feisty).

I am witnessing the same phenomenon. Only for me, it's more intermittent. I upgraded from Gutsy, but for the record, I have not seen this problem with Gutsy. I have an Nvidia 6800gt card, using the latest nvidia accelerated drivers. If I lock the machine, the screensaver activates as usual. I will test further, and report findings as I notice them.

I am not certain if this is the same bug, but wihat I am seeing is; the screesaver wont start after I turn it off, play a GL accelerated game like FlightGear or SecondLife, then turn it on again.
The screensaver will not start after the set time. The screen begins to fade but then it goes back to normal and no screensaver. It does this continuously in serial fashion at the time interval setting for Gnome screensaver to start.
If I logout then in again the screensaver does start at the time I set.
I have also found it happens when I leave the screensaver turned on but start a media player like VLC, that has simulated mouse click capability to stop a screensaver starting. When I close this application the screensaver still wont start.
It has also happened before but not always, if I start playing a streaming video in flash player, inside a browser. When I do this I turn off the screensaver because I am not sure flash player has simulated mouse clicking, then turn it on again after.
I found that none of this problem happens if I login to another user account even if I leave the normal account still loaded but just switched user.
I am using Ubuntu 8.04 (latest updates), a Geforce FX 5700 with the restricted nvidia driver from Ubuntu repositories.

Happens here too; also, an ATI. To be more specific (since for some reason this is marked 'incomplete' despite multiple confirmations of the existence of the bug):

(1) open gnome-screensaver-preferences; observe that previews for screensavers work fine
(2) set to (for example) 'regard the computer as idle after' [1 minute] and 'activate screensaver when computer is idle'
(3) close the dialog, wait one minute
(4) observe that the screen starts to fade, as if the screensaver is kicking in
(5) immediately after the screen fades to black, the screen goes back to full brightness and does not lock. EXPECTED BEHAVIOR: the screensaver turns on; if the option is selected, the screen is locked.

This absolutely should not be low importance:
(1) the software fails to fulfill its primary task (blank the screen)
(2) this is a security problem, as the screen doesn't lock.

Didn't happen with any previous Ubuntu release on this same exact hardware (which has had every Ubuntu release on it since... hrm, whatever B was?)

(hrm... will launchpad actually allow me to mark this new, since it definitely isn't incomplete?)

Ooh! I could mark new! Yay for that.

(Still won't let me fix importance; note that I also can't find a definition of 'importance', which is a launchpad bug.)

I am experiencing the exact same behaviour as Luis Villa - although I use GeForce video. Screensaver used to work before (Hardy), I only noticed a few days ago that it stopped.

However, turning compiz off and back on helps.

This was not happening when using Hardy, but since upgrading to Intrepid, the screen-saver not only fails to come on (it will queue up as it it will come on and as soon as the screen goes black, the process is interrupted, as described above), but the screen itself wont turn off after my specified time in the power settings....

John Schreck

I can confirm that this is happening on my Hardy laptop. It didn't used to happen on Hardy, but now does. The screen saver looks like it's going to kick in, but then at the last moment it stops and the screen appears as before. This also prevents power saving (like turning off the screen). If I lock the screen, the screen saver seems to work normally, including turning off the screen.

It almost seems like as the screen saver is engaging, it thinks detects a keypress or mouse movement and thinks it should not screen save. When I lock the screen, it immediately brings up the password box to unlock it, as if I had pressed a key or moved the mouse.

same situation on hardy, pentium 4, nividia agp, 3gb ram.

exactly as scott minster wrote.

As in my previous comment I am noticing the same in Ubuntu 9.04.

Now also see the same in Ubuntu 9.10 karmic. It just seems to have started in this version from the update to kernel 2.6.31-17-generic
or updates associated with the time the kernel was updated.
I have automatic update notification on, so it would have been since these became available in the repositories. I was hoping it would stay permanently fixed in karmic.

I had noticed this bug on an upgraded 8.10 -> 9.04 -> 9.10 but had assumed it was an upgrade bug, and ignored it. Now I have the same bug a clean install of 10.04. This absolutely should be a serious issue, as it could cause screen damage (imagine I go away for the week forgetting to turn off my monitor) and is a security issue (imagine forgetting to manually lock the screen).

I definitely have found that the most reliable way to initiate this bug is to deactivate the screensaver via the preferences dialog for some length of time (e.g., to watch a show on hulu.com), and then reactivate it.

I have found a work-around that's better than logging out or restarting. I have a Lock Screen applet on my panel, and right-clicking it and choosing "Activate Screensaver", after reactivating the screensaver via the preferences, will cause the screensaver to work correctly.

Note, this bug may also be related to bug #363635.

Given that this bug involves the screen fading to black, as though the screensaver were activated, before popping right back to the desktop, it seems that something is canceling the screensaver at the last moment. Does anyone know how to log the events that deactivate a screensaver?

I removed gnome-screensaver and installed xscreensaver. That does not have this bug. I still use gnome-power-manager to suspend my computer as xscreensaver only has power managment for the monitor.

After getting really frustrated with this bug, I spent most of 4th of July weekend wading knee-deep in gnome-session and gnome-screensaver code, but I finally rooted out the bugs behind this. There are two bugs:

=== Bug 1 -- gnome-session -- gsm-manager.c ===

Gnome Screensaver activates when the Gnome Session Manager's Presence module (gsm-presence.c) sends a StatusChanged signal over DBus. This signal is sent when an idle watch timer expires. When the timer expires and sends the signal, it needs to be reset. One code path to reset it is triggered when the screensaver activates or deactivates. (Notification of this is via DBus message.) Otherwise, resets are triggered by calls from gsm-manager.c that happen when a) the GConf key corresponding to screensaver timeout is changed (e.g., when the user changes the timeout in the preferences dialog), or b) an inhibitor is added or removed (e.g., when you watch a movie in vlc).

So, if the screensaver is disabled when the idle timer expires, nothing will be able to reset the idle timer. Furthermore, when the user re-enables the screensaver, the timer is still inactive, so the screensaver won't be called. Only by taking some special action, such as logging out&in, changing the screensaver timeout, or manually activating a screensaver, will the timer be re-activated.

I have fixed this by adding a callback in gsm-manager.c that watches for changes to the GConf key corresponding to the screensaver being enabled (/apps/gnome-screensaver/idle_activation_enabled). When this GConf key is changed, the idle watch timer is reset.

=== Bug 2 -- gnome-screensaver -- gs-listener-dbus.c ===

The above explains why screensavers are not triggered at all after re-enabling the screensaver. However, even with that fix, the screensaver fades out, but then snaps back to life as soon as the fade is done.

Gnome Screensaver activation is a 2-stage process: first, the gnome-session presence module sends a DBus StatusChanged signal, {gs-watcher-x11.c & gs-monitor.c} checks whether the screensaver is inhibited, and if not, begins a fade-out for 10 seconds. When the 10 seconds have expired, assuming the user has not interrupted the fade-out by doing something, {gs-watcher-x11.c & gs-monitor.c} triggers the screensaver activation. Activation is actually initiated from gs-listener-dbus.c.

Unfortunately, due to some convoluted and muddled logic in listener_check_activation and gs_listener_set_session_idle, if the screensaver is disabled when an idle session signal is received, the gs-listener-dbus.c believes that the session is idle (i.e., the screensaver is on), even though the screensaver is disabled. Then, once the screensaver is re-enabled and begins receiving more idle session notifications, gs-listener-dbus.c ignores those notifications, because it thinks the screensaver is already on! However, the fade-outs operate on a different, uncorrupted state variable, so they are unaffected. Thus, the fade-out happens correctly, but at the moment that the screensaver should activate, nothing happens and the session returns to the desktop.

My fixes to gs-listener-dbus.c maintain the correct state for the session_id...

Agghh! Ignore Launchpad's links to B U G 1 and B U G 2 in the above post. Also, the above patch should end with the extension .patch.

Here is the second patch file, which covers the gnome-screensaver patch. Read the above comment #16 for the explanation and how to apply it.

Great work Robert!

Could you please open two upstream bugs at bugzilla.gnome.org, submit your patches there, and add a link to those bugs to this one using the "Also affects project" link at the top.

Thanks!

I'm unable to test this patch as I've no access to a linux machine for a while. Testing would be appreciated, though :).

I've opened an upstream bug for the gnome-session issue here:

https://bugzilla.gnome.org/show_bug.cgi?id=625019

Upon further testing, while my previous patch does fix a code path which results in the idle watch timer not being reset, it has not fully fixed this bug. There still appears to be a race condition in which the idle watch timer is sometimes not being reset. Try as I have, I have not been able to isolate the exact reason for it.

However, I have a work-around that seems to fix the problem fully. It is the fairly ugly solution of calling reset_idle_watch from within the on_idle_timeout callback. While it might not be elegant, it does guarantee that the idle timeout is always reset.

I have tested this patch on two machines for nearly the last 3 months, and not once has my session failed to go idle, and activate the screensaver, when it was supposed to. Furthermore, I have watched for any undesirable behavior from the screensaver or session (such as, screensaver deactivating without activity, session going idle when active, high processor usage, etc.) and have seen no undesirable activity.

The following patch does *not* supercede my previous patch. For the full fix, both patches are required. The following patch is made against Ubuntu gnome-session 2.30.0-0ubuntu1.

Also, I have already submitted the above patch to upstream #625019.

In case anyone is still looking for an answer, I've found a solution.
I should first mention, I'm using Maverick on all my machines and I've only experienced the fade-then-straight-back-to-desktop problem on 2 machines with Intel integrated video, it works fine for me with Nvidia.
Since the screensaver is now handled by gnome, I checked the Configuration Editor. You'll find the screensaver settings in there under apps -> gnome-screensaver. I noticed that the "idle-delay" key was NOT set to the value I put in the gui settings (System->Preferences->Screensaver) which was 1 minute. It had 10 instead. Once I set it to 1 minute the screensaver actually started at 1 minute instead of just fading and coming back to the desktop. Hope this helps.

Stuart, the gnome-screensaver code watches the "idle_delay" gconf variable, and any change to it triggers reset_idle_watch. Your changing that variable is a work-around for those who are not comfortable with patching code and recompiling, but it's not a solution.

The precise cause of this bug has been diagnosed in my comments 16, 17, and 21, and patches have been provided to fix it. Unfortunately, it appears that my patches were never accepted by Ubuntu or upstream. What graphics subsystem you have is irrelevant to this bug.

That said, I am now using the stock gnome-session and gnome-screensaver packages in Maverick, and I have yet to experience the issue.

If you are still getting the "fade to black and then back to desktop" issue on Maverick, I recommend applying the patch in comment 21. It's only a few lines long (so it still should be valid on Maverick) and will take care of most of the problem.

My patches from comments 16 and 17 are much larger (and therefore, much more likely to have broken between Lucid and Maverick) and only are needed if you regularly disable the screensaver, wait for a while, and then re-enable it.

Under Maverick, I experienced no problems with the stock screensaver. Unfortunately, with Natty I have experienced a regression to the "fade to black and then back to desktop" issue whenever I use caffeine to disable the screensaver, and then sometime later use it to re-enable the screensaver. I am reapplying my patch from comment 21, and will report whether that fixes the situation.

The regression I reported in comment #25 is actually a new bug. See Bug #779639 for details.

I have marked this bug invalid because the bug exists (might still exist) in a package that is no longer used by default in current Ubuntu releases.