Totem uses GTK+'s APIs to prevent the screensaver from coming on. Are you using Totem under something other than GNOME?

Same problem here, running Gnome 3.10.x on Arch Linux.  System up to date, except GTK is version 3.10.4 (3.10.5 was causing some issues with nautilus).

Please let me know if I can provide any other information.

*** Bug 720418 has been marked as a duplicate of this bug. ***

Totem's inhibition will only work when running inside GNOME. You should also check that your version of gnome-settings-daemon ships with this patch:
https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=aef54ea441d5c6d27d63dee10c5cd98227d2597c

(it's in gnome-settings-daemon 3.8.6 and 3.10.1)

If those 2 conditions are met and it still doesn't work, please attach the output of:
gdbus introspect --session --dest org.gnome.SessionManager --object-path /org/gnome/SessionManager --only-properties
when reproducing the problem (eg. Totem running)

Running totem inside of Gnome, and gnome-settings-daemon is 3.10.2.

Here is output you requested:

node /org/gnome/SessionManager {
  interface org.gnome.SessionManager {
    properties:
      readonly u InhibitedActions = 8;
      readonly b SessionIsActive = true;
      readonly s SessionName = 'gnome';
  };
  node App1 {
  };
  node App10 {
  };
  node App11 {
  };
  node App12 {
  };
  node App13 {
  };
  node App14 {
  };
  node App15 {
  };
  node App16 {
  };
  node App17 {
  };
  node App18 {
  };
  node App19 {
  };
  node App2 {
  };
  node App20 {
  };
  node App21 {
  };
  node App22 {
  };
  node App23 {
  };
  node App24 {
  };
  node App25 {
  };
  node App26 {
  };
  node App27 {
  };
  node App28 {
  };
  node App29 {
  };
  node App3 {
  };
  node App4 {
  };
  node App5 {
  };
  node App6 {
  };
  node App7 {
  };
  node App8 {
  };
  node Client1 {
  };
  node Client2 {
  };
  node Client3 {
  };
  node Client4 {
  };
  node Client5 {
  };
  node Client8 {
  };
  node Inhibitor19 {
  };
  node Presence {
  };
};

Then the problem is somewhere else:
> readonly u InhibitedActions = 8;

The action is correctly inhibited.

I'm seeing the same problem as well (sounds like, from the reports so far), and have been for some time. This is under Fedora 19 (currently), and earlier, with pretty much standard Gnome 3 / Gnome Shell / Totem from the dist packages. So, currently that'd be:

totem-3.8.2-1.fc19.x86_64
gnome-shell-3.8.4-3.fc19.x86_64
gnome-session-3.8.4-1.fc19.x86_64
gnome-settings-daemon-3.8.5-1.fc19.x86_64

To expand on the pathology a bit, the issue isn't that Totem fails to inhibit the screensaver while playing video. That works fine: no matter the duration, the screen will stay active for the entire video.

The problem occurs in situations where multiple files are queued in totem's playlist, when it advances from one file to the next. It appears that totem "drops" the inhibition, at least momentarily, when doing so, allowing the screensaver to reactivate despite the fact that totem is actively playing the subsequent playlist entry.

So, steps to reproduce:
1. Launch totem to play file MOVIE1.mp4
2. Add file MOVIE2.mp4 to playlist following MOVIE1.mp4
3. Watch MOVIE1.mp4 through to the end
4. Simultaneously, MOVIE2.mp4 begins playing, and the screensaver activates
5. The opening seconds of MOVIE2.mp4 disappear as the screen fades to black

Depending when I catch the activation and attempt to wake the screen, a mouse-movement will either unblank without incident, drop me at a black screen where I have to use Alt-Tab or the Super key to return to the desktop, or (worst case, and infrequently) lead to a Gnome Shell crash and relaunch. Totem is usually autopaused following the latter two, IIRC.

(In reply to comment #7)
> The problem occurs in situations where multiple files are queued in totem's
> playlist, when it advances from one file to the next. It appears that totem
> "drops" the inhibition, at least momentarily, when doing so, allowing the
> screensaver to reactivate despite the fact that totem is actively playing the
> subsequent playlist entry.

Ha, that makes more sense. We should probably do something on the gnome-settings-daemon side still, but I've added a work-around in Totem, so that inhibition isn't released in between 2 movies. This is fixed in the version of Totem for GNOME 3.12:

commit b0466cbb6345cf7bcfe30fee254b9df1bb478d22
Author: Bastien Nocera <hadess@hadess.net>
Date:   Sun Jan 26 14:46:08 2014 +0100

    screensaver: Wait 5 seconds before uninhibiting screensaver
    
    Otherwise the screensaver might come on in between 2 movies.
    
    See https://bugzilla.gnome.org/show_bug.cgi?id=705942#c7

That doesn't make a lot of sense to me. The way inhibiting is supposed to work is that the system is considered "active" while an inhibit is in place. Therefore, when all inhibitors are dropped the system will start the timer for locking the screen, if no other input is received. There should be no way that the lock timeout is smaller than the time it takes to start another video. So, is there something wrong with how we handle idle?

re: comment 9, I'm in agreement that what you describe is how it "feels" like inhibit should work, but in practice that doesn't seem to be the reality of it at present. Perhaps that's the real bug here.

It's similarly disconcerting how, as totem reaches the end of its playing stream / playlist on a system that's received no other input activity, the screensaver kicks in and executes a fade-to-black the moment it finishes. (Or, I guess 5 seconds after, with this change.) That is precisely what I've observed on my Fedora desktops, though, under the current idle/inhibit mechanics.

It would seem more natural/expected, from a user's point of view, if the system were to consider the inhibiting process as "user activity", and start the idle timer counting from 0 once the inhibit flag is lifted, rather than crediting "time served" on input idleness during the inhibit window.

(I suppose it's an open question whether that should be equally true of all inhibit types, though. If powersave is inhibited due to a yum transaction or a long filesystem operation — any sort of unattended operation (in contrast to watching a video, which is very much an attended activity) — then you could argue that letting the idle timeout fire immediately once it's given the "all-clear" is the right approach.)

*** Bug 772943 has been marked as a duplicate of this bug. ***

WebKitGTK+ 2.20 now takes a sleep inhibitor when playing video, and releases it when playback stops. This causes GNOME to begin blanking the screen immediately after video playback completes. Desired behavior would be for the sleep to be delayed for five minutes (the configurable timeout) after the inhibitor is released.

This is impossible to fix at the gnome-settings-daemon level, because the API we use (X11+mutter or mutter -> GnomeIdleMonitor in gnome-desktop -> gsd-power) doesn't allow this.

The idle time is global (gnome_idle_monitor_get_idletime()), so calling gnome_idle_monitor_add_idle_watch() will trigger its callback at the same time whether you set it up just after you became idle, or 5 minutes after you became idle.

Ideally, inhibited would be considered active, but I'm not sure that mutter depending on gnome-session is a good idea architecturely. A way for gnome_idle_monitor_add_idle_watch() to start from this point _might_ allow us to fix it, but it won't make gnome-settings-daemon's code any clearer.

Let's reassign this to mutter, as we'll need API to start with.

How does a gnome_idle_monitor_reset_idletime() method sound to you? This would be easy to add to mutter, and I suppose gnome-session(?) could then call this just before releasing inhibitors.

(In reply to Florian Müllner from comment #14)
> How does a gnome_idle_monitor_reset_idletime() method sound to you? This
> would be easy to add to mutter, and I suppose gnome-session(?) could then
> call this just before releasing inhibitors.

That would work, although I'm not sure how you'd implement that under X11 (fake an input? pretty ugly) and I'm worried about other applications using idle time for a different purpose, one that wouldn't take inhibited idle time into account.

(In reply to Bastien Nocera from comment #15)
> That would work, although I'm not sure how you'd implement that under X11
> (fake an input? pretty ugly)

I was assuming that calling XSyncSetCounter() works on the IDLETIME counter, but I don't actually know that and didn't check.


> I'm worried about other applications using idle time for a different
> purpose

Mmh yeah, I didn't think about this. Although if we consider inhibited to be active, then maybe that would be the correct behavior anyway?
(As far as GnomeIdleMonitor is concerned, not necessarily the underlying X bits)

(In reply to Florian Müllner from comment #16)
<snip>
> > I'm worried about other applications using idle time for a different
> > purpose
> 
> Mmh yeah, I didn't think about this. Although if we consider inhibited to be
> active, then maybe that would be the correct behavior anyway?
> (As far as GnomeIdleMonitor is concerned, not necessarily the underlying X
> bits)

Well, if it's gnome-settings-daemon calling reset when the inhibition has finished, then idle monitor for lower values will still trigger.

Hm, did you consider allowing idle inhibitors to abort the long fade-to-blank animation done by the shell? i.e. we already have the 20s delay before the screen is actually locked and that should give applications plenty of time to re-grab the idle inhibitor when the next video starts.

The behaviour would be:
 * Screen is locked 20s after the last video finishes
 * Consecutive videos will not cause the screen to be locked
 * fade-to-black might be visible for a short period of time (maybe 1s or so)

(In reply to Benjamin Berg from comment #18)
> Hm, did you consider allowing idle inhibitors to abort the long
> fade-to-blank animation done by the shell?

That's implemented directly in gnome-shell.

> i.e. we already have the 20s
> delay before the screen is actually locked and that should give applications
> plenty of time to re-grab the idle inhibitor when the next video starts.
> 
> The behaviour would be:
>  * Screen is locked 20s after the last video finishes

Well, the problem is that it's not the behaviour we want.

>  * Consecutive videos will not cause the screen to be locked
>  * fade-to-black might be visible for a short period of time (maybe 1s or so)

(In reply to Bastien Nocera from comment #19)
> (In reply to Benjamin Berg from comment #18)
> > Hm, did you consider allowing idle inhibitors to abort the long
> > fade-to-blank animation done by the shell?
> 
> That's implemented directly in gnome-shell.

Well, if this was implemented, then the issue with the screen locking between two videos wouldn't exist, resolving this bug.

> > i.e. we already have the 20s
> > delay before the screen is actually locked and that should give applications
> > plenty of time to re-grab the idle inhibitor when the next video starts.
> > 
> > The behaviour would be:
> >  * Screen is locked 20s after the last video finishes
> 
> Well, the problem is that it's not the behaviour we want.

Sure, fine with me, if that is actually what we want. I was simply asking as there didn't seem to be any rationale given why switching the definition of an inhibitor from meaning "prevent session from being marked idle" to "consider session to be active". And I don't think that changing this definition is a requirement to fix the original bug.

This has become rather more urgent, because after bug #681869 the system now suspends immediately when YouTube video playback ends, without any opportunity for the user to prevent that. (I haven't seen this myself, because I have not upgraded to F28 yet, but it's been reported in https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/14.) This is in contrast to screen lock, which provides the user with several seconds in which to wiggle the mouse while the fade animation takes place.

We need to immediately revert bug #681869 until this bug can be solved.

Created attachment 369899 [details] [review]
backends: Remove X11 idle-monitor backend

And use the old "native" backend for both X11 and Wayland. This will
allow us to share fixes between implementations without having to delve
into the XSync X11 extension code.

Created attachment 369900 [details] [review]
idle-monitor: Take idle inhibition into account

Take idle inhibitions into account for when to fire idle watches as
requested by OS components.

This should stop gnome-session and gnome-settings-daemon considering
the session idle when they have been inhibited for longer than their
timeout, for example to avoid the screensaver activating, or the
computer suspending after watching a film.

This is just compile tested. Possible problems:
- requires gnome-session as the session handler
- not sure how things will behave when shell is restarted on X11
- the gnome-session cut'n'paste might need to be in a separate patch
- loads of code changes for a stable release

I'll let a mutter developer take it from here.

(In reply to Bastien Nocera from comment #24)
> - loads of code changes for a stable release

Yeah, I won't personally be granting a freeze exception for something this big... another good argument for temporarily backing out the autosuspend feature in 3.28.

The first patch has a little which I'm still hunting down, using g-s-d's power test suite. It looks like events sent using XTest[1] are just plain ignored by mutter, but running as the window manager it's supposed to receive it.

[1]: See gpm-common.c in g-s-d for the code.

Created attachment 369951 [details] [review]
backend: Reset idle when lid is opened or resuming from suspend

There's no particular reason for this code to only ever be triggered on
Wayland, and allows removing X11-specific work-arounds from
gnome-settings-daemon.

See https://bugs.freedesktop.org/show_bug.cgi?id=59576

Created attachment 369958 [details] [review]
idle-monitor: Add ResetIdletime API, for testing purposes

The ResetIdletime API can be used instead of an "XTest" binary to
programmatically reset the idle time, as if the user pressed a button on
a keyboard.

This is necessary since we stopped using the XSync extension to monitor
idletimes, as it didn't consider inhibitors as busy, and mutter's
clutter code ignores "Core Events" as generated by XTest.

This patch will require minimal changes to gnome-settings-daemon's power
test suite so that "key press" idletime resets are triggered through
this D-Bus interface rather than through XTest and a roundtrip through
the X server.

MR is here: https://gitlab.gnome.org/GNOME/mutter/merge_requests/54

gitlab is where things are happening.