idle/screensaver inhibition feature doesn't work reliably

Thank you for your bug report. The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

Thank you for sending the bug to GNOME

I can reproduce this bug on opensuse 11.2 too. This is a upstream bug.

Upstream replied that they fixed the warnings in totem, and that they "couldn't reproduce the problem, but I can see how the original warning might happen. Most likely, gnome-screensaver crashed, or was killed, and the gnome-session inhibition didn't notice. gnome-screensaver is supposed to proxy to
gnome-session, and it should be transparent to users."

Bastien finished by: "File a bug against gnome-screensaver if you still see the problem."

Now the question is whether we will still be affected now that a fix for the warnings has been committed in totem, or if gnome-screensaver is still problematic, or something.

Luis, could you help doing some additional testing on this? I'm not sure how to proceed myself.

It also affects EoG when you use fullscreen/slideshow:

jeff@kusanagi:~$ eog Capture.png

(eog:2262): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Method "InhibitActivation" with signature "s" on interface "org.gnome.ScreenSaver" doesn't exist

** (eog:2262): WARNING **: Problem inhibiting the screensaver: Method "Inhibit" with signature "ss" on interface "org.gnome.ScreenSaver" doesn't exist

But then I'm not sure if it's the same kind of bug (probably not) and if I need to file a new launchpad report for this.

do you have gnome-screensaver running?

Yes, along with gnome-session and gnome-power-manager.

I did some further testing, and indeed, eog causes the same kinds of problems as totem did: if you use fullscreen once, you won't have working session idling (ie: eog doesn't uninhibit, it seems) until you logout.

I just filed https://bugzilla.gnome.org/show_bug.cgi?id=599139 upstream, but I don't know how to retroactively link to a second upstream bug from launchpad...

the fact that you get the same issue on different softwares suggests it would rather be a gnome-screensaver bug

Well, now I filed a third bug, https://bugzilla.gnome.org/show_bug.cgi?id=599196 hoping that it gets anywhere...

Responding to your list comment, the issue is not a blocker because there is only one user running into it so far you, and the bug without steps describing how to trigger the issue is not easy to work on, would still be nice to get fixed though

In the hope that it can help as per previous comment, here are some
steps for reproducing:

- in gnome-power-preferences, set the screen to blank after 1 minute of
inactivity
- (optional?): in gnome-screensaver-preferences, set the session to go
idle/screensaver to activate at 1 minute

Now, logout and login (to make sure you have a clean session). Then:
1. do nothing for 2 minutes. The screen should blank. If you have
empathy running, the status should become "Away"
2. move the mouse or type something, the session becomes active again
3. to break this normal cycle, open any image (with the default image
viewer, eog), go in fullscreen (F11) or slideshow mode (F5), the message
'Method "InhibitActivation" with signature "s" on interface
"org.gnome.ScreenSaver" doesn't exist' will be printed in the terminal
if you ran it from a terminal.**
4. close eog*
5. wait as long as you want, the session will not go idle.

*: step 3 can (at the time I am writing this) be tested also by playing
any movie with totem, then exiting totem
**: for some reason, this happens on my generic desktop machine, but not
on my lpia netbook.

After further testing, I was able to determine that this is not
architecture/package-specific either. Creating a blank account account
on this computer, I can see that only my main account is affected, so it
must be the usual "broken/corrupt configuration" problem.

The problem is that I have no idea where to look. I have tried resetting
gnome-power-manager's gconf values, removing various folders in
~/.config, ~/.gnome2/, ~/.local/share/, etc. Advice on what to look
at/attempt would be welcome!

Is anyone here using the hamster-applet?

There's likely only one issue affecting totem and eog here. Closing the eog task for now

Yes, using the hamster applet, what about it?

I've spent some time debugging this, and actually found a bug in the hamster-applet which triggers the behaviour described here. hamster-applet is watching all messages on the org.gnome.ScreenSaver interface, but doesn't handle them correctly, causing dbus to return an error even when the message is handled correctly by gnome-screensaver. See https://bugzilla.gnome.org/show_bug.cgi?id=600909

I often have the case that the screenblanker does not kick in if I don't use the computer, but if I touch the mouse again, it suddenly activates. Is this a separate bug to this?

Just checking the pulse here, from what I understand this has been fixed
upstream by hamster. Will the fix be backported to the karmic package?

I've built an updated hamster-applet package in the following PPA:

https://launchpad.net/~mdeslaur/+archive/screen-locking

Please try it, along with the gnome-screensaver security update for karmic that came out a couple of days ago, and give feedback here.

If this solves the problem, I'll push it as a karmic security update.

Thanks.

Marc - I had a look at the patch from upstream, and I still think it's wrong. I was going to propose a different way to handle this upstream, but haven't had a chance to look at it properly yet. hamster-applet really shouldn't be intercepting and handling messages on the org.gnome.ScreeSaver interface at all, and it still does that even with the upstream change (albeit, D-Bus doesn't return an error anymore, like it does currently)

I agree that hamster-applet shouldn't be doing that, and will be looking forward to your better way of handling it.

Meanwhile, the ugly fix will help with screen-locking issues, and I'd rather get something out that at least takes care of the issue sooner rather than later.

I'm looking forward too.
Marc - where can i see the ugly fix you are referring to?

Marc - Ok, I'm happy with going with the current solution in Karmic for now then, as long as it solves the issue. It also has minimal regression potential for hamster-applet.

I'll have a think about a longer term solution over the next few days though, and propose that to upstream.

Thanks

Chris - if you are up to the task, I can well suggest looking in two places.
First the DBUS should be able to survive invalid listeners.
Second, it might be useful that screensaver / gnome session DBUS API differentiate between a user-requested screen lock and idle timeout, because that is what hamster is trying to deduce.

Tom:

Sorry, I didn't meant the fix was ugly, I just meant releasing an update with it is less ideal than the type of solution Chris was proposing. A bad choice of words on my part.

This is the commit I put in the test package:

http://git.gnome.org/cgit/hamster-applet/commit/?h=gnome-2-28&id=a3bf20acad703417f694fa604f7a0a0690e69303

> I've built an updated hamster-applet package in the following PPA:
>
> https://launchpad.net/~mdeslaur/+archive/screen-locking
>
> Please try it, along with the gnome-screensaver security update for
> karmic that came out a couple of days ago, and give feedback here.

I gave it a shot, tested with totem, hamster, fullscreen eye-of-gnome,
with
- screensaver
- screen blanking
- automatic suspend/sleep/whatever

...and it works! Great! :)

On a side note, I did have the impression that my netbook (also running
9.10, but not running hamster applet) also sometimes had a problem with
session idling, suggesting the possible presence of *yet another* bug on
top of all this, but maybe it was just my imagination; I am not really
qualified enough to investigate that. Time will tell, or maybe Chris
Coulson knows about "other" session idling problems?

In any case, the most visible part of this bug is fixed by the (not
optimal, but working) hamster patch.
It feels all warm and fuzzy to finally have working session idling
again.

The updated hamster-applet from comment #21 does not seem to fix anything for me:

Still, the Screenblanker sometimes "forgets" to kick in. In these cases, the moment I move the mouse again, the screen fades out as if the Screenblanker is about to activate, but then switches back on (probably because of the mouse move).

Also, the "Lock" keyboard shortcut (Ctrl-Alt-L) does not work when a menu (e.g. in Firefox: Help Menu) is visible.

Andreas:

Those are different issues. Could you please open two new bugs for them, and we'll get them investigated.

Thanks.

This bug was fixed in the package hamster-applet - 2.28.0-0ubuntu1.1

---------------
hamster-applet (2.28.0-0ubuntu1.1) karmic-security; urgency=low

  * SECURITY UPDATE: broken screen-locking idle timeout (LP: #448438)
    - debian/patches/01-fix_inhibit_cookie: fix screensaver inhibit issue.
 -- Marc Deslauriers <email address hidden> Wed, 09 Dec 2009 09:26:52 -0500

Re-opening. This shouldn't be marked Fix Released as the fix is not present in Lucid.

This bug was fixed in the package hamster-applet - 2.29.4-0ubuntu1

---------------
hamster-applet (2.29.4-0ubuntu1) lucid; urgency=low

  [ Robert Ancell ]
  * debian/control.in:
    - Remove old debian VCS links

  [ Andrew Starr-Bochicchio ]
  * New upstream release. (LP: #488783)
   - Fixed problems with hamster interfering with
     screensaver hibernation code. (LP: #448438)
   - Fixes to the dropdown in compiz (not spanning
     over virtual desktops anymore). (LP: #303572)

  * Merge with Debian testing, remaining Ubuntu changes:
   - Adapt debian/watch to take unstable version.
   - Point Vcs field at lp:~ubuntu-desktop/hamster-applet/ubuntu

hamster-applet (2.28.1-1) unstable; urgency=low

  * New upstream release.

hamster-applet (2.28.0-1) unstable; urgency=low

  * New upstream release.
    - Fixes to idle detection (Closes: #538790).
  * debian/control.in:
    - added a depends on python-gnome2 needed at runtime.
    - removed python-glade2 depends, it's no more needed.
  * debian/copyright:
    - added missing copyright holders.
  * debian/patches/01_startup-fix.patch:
    - this patch removes the __file__ test at startup preventing
      hamster to fail when loading needed modules.
  * debian/rules:
    - added simple-patchsys.mk include.
 -- Andrew Starr-Bochicchio <email address hidden> Tue, 22 Dec 2009 17:52:52 -0500