Screensaver activates during video playback

Bug #474175 reported by Kevin Knerr
54
This bug affects 11 people
Affects Status Importance Assigned to Milestone
gnome-screensaver (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: gnome-screensaver

Ubuntu 9.10, gnome-screensaver 2.28.0-0ubuntu3

To reproduce: start watching a video (which is longer than your screensaver idle tie). Enjoy the video and keep your hands away from the keyboard and mouse. The screensaver starts.

Expected behavior: The screensaver doesn't start counting idle time until the video ends.

I am filing against gnome-screensaver because I've observed this behavior with both Totem and vlc in Karmic. Since this behavior has changed since Jaunty, I suspect either a bug in gnome-screensaver or a change in how to inhibit the screensaver which breaks the prior mechanism used by totem and vlc (and possibly others).

I did see a note in the changelog about getting idle time from xorg. If that is the cause of this issue, I would be happy to post bugs against Totem and vlc, but it would be more effective if I could include information about how to properly inhibit gnome-screensaver.

ProblemType: Bug
Architecture: amd64
Date: Wed Nov 4 06:10:34 2009
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
NonfreeKernelModules: nvidia
Package: gnome-screensaver 2.28.0-0ubuntu3
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: gnome-screensaver
Uname: Linux 2.6.31-14-generic x86_64

Revision history for this message
Kevin Knerr (ld-barthel) wrote :
Revision history for this message
freddy3980 (freddy3980) wrote :

This bug also affects SMPlayer/MPlayer.

Revision history for this message
larsemil (emil-larsemil) wrote :

confirmed on two of my computers and also a friends so it seems like it is a common problem,

Revision history for this message
Dirk Schedler (schedler-sscs) wrote :

I can confirm this issue as it affects me too.
Bug reproduced with Kaffeine
Also affects VNC Player, doesn´t matter if the option "disable screensaver during video playback" is set or not.

Revision history for this message
Brice Marnier (brice-marnier) wrote :

I've just tried to reduce screensaver activation time to 1 minute, and launched several tests:
It does not affect mplayer (v4.4.1, no GUI, vo=xv, waited for 3 minutes and no screensaver activation)
Screensaver activates with VLC (1.0.2 goldeneye) after just one minute.
the same goes with Xine (v0.99.6cvs) and - believe it or not - gmplayer (v4.4.1) ! ...

mplayer seems to be a good start to track down this bug, does'nt it ?
Next step : check config files.
I've tried changing stopxscreensaver from "yes" to "no" in ~/.mplyer/gui.conf : no effect.
I've tried removing ~/.mplayer/gui.conf file (and let gmplayer create a brand new one) and it fixed the problem : no more screen saver !

Tracking down differences, I reverted options to the ones I had in my "not working" conf file.
restoring vo driver to sdl:hwaccel : no effect
restoring vo_direct_render to "yes" : my hue goes wrong, but no screensaver bug.
restoring vf_pp to "yes" : nothing.
restoring old config file completely : nothing. In fact screensaver is completely disabled and does not start even without mplayer running : I have to redo my tests !!!
I won't be longer, but I've been running some tests and encountered more screensaver de-activations and could not determine the faulty option in config file...
The good thing is that gmplayer with its default config file behaves correctly on my system. freddy3980, it would be nice to check if reseting your gui.conf does the trick, too.

Revision history for this message
Leo (llenchikk) wrote :

I can confirm this issue too.
I have this problem watching video from vlc. Watching video from totem have not this bug.

Changed in gnome-screensaver (Ubuntu):
status: New → Confirmed
Revision history for this message
Kevin Knerr (ld-barthel) wrote :

https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/428884 seems to point to the core issue.

'gnome-screensaver-command --poke' sends a "SimulateUserActivity" message to the screensaver. Checking gs-monitor.c, we find the following:

--- gnome-screensaver-2.24.0/src/gs-monitor.c 2008-08-20 20:53:34.000000000 -0500
+++ gnome-screensaver-2.28.0/src/gs-monitor.c 2009-08-19 18:19:14.000000000 -0500
@@ -231,9 +186,7 @@
 static void
 gs_monitor_simulate_user_activity (GSMonitor *monitor)
 {
- /* in case the screen isn't blanked reset the
- idle watcher */
- gs_watcher_reset (monitor->priv->watcher);
+ /* FIXME: reset the xsync timer? */

         /* request that the manager unlock -
            will pop up a dialog if necessary */

NOTE: I've only included the interesting porition here. The complete diff is attached.

It appears that the mechanism for simulating user activity has been stripped from gnome-screensaver-command. I suspect that the new FIXME is a requirement of getting idle time from Xorg, since the gs_watcher_reset function is no longer present in gs-watcher-x11.c.

I'm going to look into workarounds, since I don't have the expertise to fix this issue myself. If I were a new user encountering this kind of behavior, however, I think I'd be discouraged from using Ubuntu. I strongly suggest that this issue be corrected for Lucid LTS. Otherwise we need to consider alternatives to gnome-screensaver.

Revision history for this message
Kevin Knerr (ld-barthel) wrote :

If I read http://svn.gnome.org/viewvc/gnome-screensaver/trunk/src/gs-monitor.c?view=log correctly, the FIXME was introduced in rev 1578 on 18-Jan. There has been no activity since 20-Jan on gs-monitor.c.

As a workaround, I did the following (in a root terminal):

cd /usr/bin
mv gnome-screensaver gnome-screensver.karmic
cp -a /media/Jaunty-64/usr/bin/gnome-screensaver gnome-screensaver.jaunty
cp gnome-screensaver.jaunty gnome-screensaver
(I then performed the reboot required for today's kernel update.)

This was sufficient to restore the desired behavior. I've noticed no problems after my brief testing.

Notes:
1) "Jaunty-64" is my old 9.04 root partition. Not everyone would have this available. In that case, downloading the appropriate jaunty package and exploding it (dpkg-deb --extract) would provide the appropriate file.
2) I chose to do copies instead of symlinks so that a future package update won't clobber my jaunty copy.

It may be possible to manually install the jaunty package, forcing the version. However I have no idea how that may affect the rest of the system. Besides, that would hide any new updates that might correct the problem.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.