gnome-screensaver activates while playing SDL games

I see the same problem when playing Unreal Tournament 2004 (native Linux AMD64 version). When playing the game full screen, suddenly the image fades away, and the screensaver is started. This never happened with xscreensaver.

I took the time to register and report this bug upstream, as dholbach suggested on IRC, and just as I suspected, they closed it saying it isn't a bug.

BUT, the purpose of a screensaver is not to mess up end users who are playing games or watching movies. Its purpose is to do two basic things:

1) Allow the screen to be locked while being temporarily away from the PC
2) To have something constantly moving on the screen (or alternately have a blank screen), to avoid burn-in images.

If I am watching a movie or playing a game, I am not going to be temporarily away from the PC, and locking the screen is not something I will want to do, so #1 is not needed.

If I am playing a game or watching a movie, then the screen is constantly changing, and therefore I am avoiding burn-in images, nullifying #2.

I am not the only one who found this "functionality" to be a pain, and I think that the upstream attitude of "it should be changed in every other application" is wrong.

Xscreensaver used to work just fine, and I think that given the circumstances, it should remain default in Dapper, until either upstream changes their tune, or every other application (which may or may not be actively maintianed) modifies all of their applications to work around a new screensaver design.

The alternative is to leave gnome-screensaver as default and deal with many unsatisfied and annoyed users.

When playing a game you should still be using the computer--mouse and keyboard input should be detected and screensaver should not activate. If this is not the case, then this is definitely a bug.

If you actually are not pressing any buttons in your game for longer than your -chosen- screensaver timeout, then (that game really sucks!) you should just increase the screensaver idle timeout setting, and contact the game developer to ask them to disable screensaver on their game. I do find it rather odd that a game would have that long of a no-input sequence as to activate the screensaver. Maybe you just have it set ridiculously low (<10 min?)...

@hackel

No, this happens even when i'm playing a very busy game of tuxracer. It seems that, as soon as the game is started, the screensaver thinks it doesnt receive any input. So if the screensaver is set to 10 minutes or so, then after 10 minutes of playing the screensaver kicks in.

Using the latest Dapper, I'm getting this for things other than games as well. The screensaver will kick in while using Epiphany or Firefox during constant web activity. It has happened several times today while I've been in the middle of typing, once while entering a different bug report. This is a definite regression compared to Breezy.

I can confirm this bug, this happened to me while I was typing (!) a text in Openoffice 2.0 (in Dapper)

Oh, my bug seems to be related to upstream #332576, so I will add a watch for that.

There seem to be 2 different bugs, one in the (full screen) applications that don't tell the screensaver to not activate (these should be filed upstream in the applications) and another one somewhere else that happens after you put your computer to sleep.

I might be wrong, but I think a separate bug should be filled against each application unless these games are using a common system (like games built with SDL). So it should be one bug for gnome-screensaver starting with tuxracer, one for gnome-screensaver starting with frozen-bubble, etc...
Which means I'm not so sure Bug #33734 should really be marked as a dupplicate for this bug. The description of this bug "Screensaver activates while playing a game" seems a bit too vague (some games prevent gnome-screensaver from running, mainly desktop games like gnome games). But I could be wrong :)

If you have a look at the upstream gnome bug #333280 this is exactly the procedure that the developer suggested there.
Still, there is a issue about gnome-screensaver activating after a suspend, which is different then the games thing.
I agree that, bug #33734 is not a duplicate of this one. I would suggest to open a new bug about the suspend issue and one for each application which is failing.

Loic, all the games I tested that activated the screensaver while playing were SDL games that used the keyboard only. Some of them would prevent the screensaver from coming on if you moved the mouse, but not all of them. (moving the mouse in games that do not require it is not any more of a solution than moving the mouse every 9 minutes while watching a movie).

I no longer have the time to file bugs on every single game as I thought I would, but because the ones I did test were all using SDL, I think the better option is indeed to file this single bug under SDL, and add something to the keyboard handler routine or so.

Note that this would also have the benefit of fixing commercial games (which are NOT going to be fixed by having their own bugs opened in this bug tracker) such as Professor Fizzwizzle, which is also on the list of games that use SDL and do not use the mouse and do not prevent the screensaver from activating.

Reporting bugs on 25-30 games individually is going to substantially increase open bug reports, email traffic, and the Ubuntu-debian delta. I think we ought to take the efficient route. Getting one patch for SDL accepted upstream will likely be much easier than 25-30 different games. And commercial games on top of that.

Then we need to edit this bug's description and add SDL as affected by this bug. That way other bug reports for games linked against SDL can be marked as duplicates of this bug, and for the others we'll have to keep filling bugs (unless gnome-screensaver is dropped, but I don't think it's ever going to be considered).

However, I know even less about SDL games, so it's better you do it (you reported the bug), else we'll have to keep praying for "somebody else" to write an usefull bug report, which doesn't seem to be happening.

Usually, when the bug report is precise enough, it's fixed faster (that means being really precise about what to fix. Here, gnome-screensaver is not the application which code will be modified). At least, that was the case for vlc and xine.

I'm noticing that a ton of bugs are showing up for specific games having problems with gnome-screensaver. I've been marking related bugs for games that use libsdl1.2 as duplicates of this one.

I'm highly skeptical of the gnome-screensaver folks marking the upstream generic version of this (not libsdl specific) as notabug. gnome-screensaver should be catching ALL inputs. Somehow, and for some reason, gnome-screensaver isn't catching the inputs sent to libsdl1.2.

I'm re-adding gnome-screensaver as affected until we get more info.

A quick dependency check shows about 15 supported apps that depend on libsdl1.2. There about 240 packages total (universe/multiverse included) that depend on it.

I vote for this bug being marked as high importance, because it is affecting several supported apps in the main component (although they are priority optional).

how are we supposed to fix and support libsdl1.2 to disable gnome-screensaver, if the gnome-screensaver dbus api is currently unstable? It is therefore my opinion that gnome-screensaver is broken, and I think gnome-screensaver should be patched to detect all input activity.

I went ahead and tested the patch found on gnome bug #342728, which I've included here. It seems to have fixed the problem. I ran a full screen SDL game, and the screensaver never activated. I ran the same SDL game in a window, and the screensaver activated, but gave me back control when I deactivated the screensaver.

However, it needs more testing, because I created a patched version of Dapper's gnome-screensaver-2.14.2, but the fade feature somehow didn't get enabled. The fading may be part of the issue, so I'm requesting that someone with more experience apply the patch and test the results.

This also appears to have fixed bug #48108.

the patch is now applied upstream in gnome-screensaver 2.16. You should test if it works for you now.

bah, sorry for the noise, but g-s 2.16 is in edgy, of course. I'll mark this fixed for now, please reopen if the issue still persists after upgrading to Ubuntu 6.10.

libsdl1.2 is not to blame, marking rejected.

I don't agree to mark this bug fixed, I would really like to see this fix in Dapper, too. Is there a way that it can be backported?

ok, marking this for dapper. It should be assigned to someone too..

acording to bug #52275, it's security vulnerability.

Ogra, could the patch from upstream be applied to dapper?

on a second thought, it is quite large :/

Same goes for Feisty, I'm sure this didn't happen in Edgy. I play UT2004 quite often and now the screensaver kicks in, it's really annoying UT2004 flashes for a couple of seconds and I got back into UT2004 (because im hitting the keyboard + moving the mouse pretty much constantly). It's pretty annoying. Right now I'm doing sudo killall gnome-screensaver because it really is a nuisance.

It's probably a regression, please fix :)

It looks like there was a regression somewhere. I am not sure if my problem is exactly the same or not, though. I have submitted a bug on it—bug 105249.

Also getting the fade out on xmoto and sauerbraten, both sdl games

On Gutsy, the bug is still there even though upstream claims to have fixed it on 2006-07-27

Merely trapping keyboard input as well as mouse movement may not be sufficient, especially for games that are primarily played with a joystick, gamepad, or other specialised input device. Ideally the screensaver should trap on any input events, regardless of source.

This bug is causing problems with keyboard and mouse input in UT2004. When gnome-screensaver tries to activate, the keyboard and mouse would seem to reset. All of a sudden, I'd be facing down, and whatever key I was holding stops registering until I let go and press it again. It took me a while to figure out this was caused by gnome-screensaver because I don't actually see it activate. It just eats my input while I'm playing. A couple of other people have encountered this as well.

Here are the relevant threads:

http://ubuntuforums.org/showthread.php?t=557543
http://ubuntuforums.org/showthread.php?t=595869

I think upstream isn't aware of this bug, maybe someone should open a new bug. Probably to the gnome-screensaver developers.

I also have this problem on my Ubuntu 7.1 at the date Feb 8th, 2008.
When I playing the game "Chromium" using only the mouse, after sometimes the screen saver appears and locks the computer.

See related bugs at:

https://bugs.launchpad.net/ubuntu/+bug/163865
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/155263

The bugs above seem to be related to having Compiz and the screen saver enabled while playing certain games.

Negative. I have had Compiz disabled the day I installed Gutsy (various problem, and no way to get the Exposé-like feature from Feisty's, which was the only function I found useful. The screensaver problem appears whether you are using Compiz or not.

I only have this problem when compiz is enabled. All the games I play fullscreen have this problem, no matter the input. If I disable compiz, the problem goes away.

The bug is still there on Hardy Heron, but it seems to only affect games that doesn't receive any mouse or keyboard input, for example games I play with a usb joypad.. very annoying..

It's not a bug, it's a feature...(Bill Gates, circa 1995) This problem continues in Intrepid. As the fellow mentioned above, UT2004 goes from fullscreen to windowed and becomes unresponsive. Sometimes I can recover by minimizing/maximizing UT2004 sometimes I have to Cntl/Alt/Bksp to restart gnome.

I opened a new upstream bug report, the old one didn't seem to be related to this bug. Let's see what GNOME developers think about this.

The same happens with Lbreakout2.

My kids have discovered that minimizing the window and maximizing again brings the game back to life.

On 9.04, it still happens, Whenever I have COMPIZ turned on, I can't play games.

If I turn off compiz, it works fine!

Cheers

With Ubuntu 9.04 I cant play AssaultCube because of this bug. The screen saver tryes to activate while I'm playing, and it completely messes my game..

Confirming this as a bug under Ubuntu Jaunty x86_64 bit, was the same with Intrepid, screensaver locks up both Eduke32 and latest Doomsday, both using SDL. I have to run them windowed or disabled the screensaver before playing.
Only program that truly disables the screensaver successfully is VLC, not sure about totem because I hardly ever use it. :p

Con'on, that bug has been submitted 3 years ago and is still unfixed?
And, since compiz is enabled by default in newer relases, it should be a priority, shouldn't?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

This happens to me regardless of whether Compiz is enabled or not.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEcBAEBCAAGBQJKIb6VAAoJEIltSrFpUGtehfEH/0JA5s3NeHUJtjhPdjVO49E1
JLq1N2igphkwd2hrSzZdR2X2Iocdord3QZPAWlt0kqnLCwst9TQ4Q7TNQu/PJ2+N
N1GUwoyHe0RWVq9bkijy8QWpZwcZ+thtvThz8pBBhHpdrJDq4pjIHPnlW/9iq1Pa
JyXDv082jV9H1QVTMl2TO/15ShezbaTH3DqgxA9lBttjRxvjoC9wO0yB/n7ROt8X
VgB+5cUjJQNxUH3DnqdcSnnjfnyvW/NYlJ5RQkf5/fzW0ApEJ3w45BudFDQD2TYz
lkMCtsRwZTcIXHax+MgLViRJ+ALgX5Q7WaQaZH1tGEoqYLFnp8aYUqXdJjqlwgA=
=svpV
-----END PGP SIGNATURE-----

I can confirm this bug in with DOSBox and Planet Penguin Racer, both of which use SDL in Hardy. I added a few more duplicates to the list. Hope this gets fixed soon.

I've had this problem since 8.04 (maybe as far back as 7.10, fuzzy on memory) with UT2004 and other games, exactly as ToastyX and others described. Still have this problem in 9.04.

I found if I use Metacity instead while playing, I have no problems (alt-f2, "metacity --replace").

Is there any progress on this being fixed?

There was a fix relased for edgy (see post 14) and we never heard of this problem in Feisty, but it came back in Gusty.

Maan, this is the second top bug in importance for gnome-screensaver, what's wrong with this program?

I've noticed a similar problem lately (it's not a new problem, just quantified it now) with other games (besides UT2k4 as I mentioned). UT2k4 never likes to let go of the mouse, but several other games I've played (Quake 3, zdoom; both open source) will release the mouse on certain events it doesn't need it, like when the game's console is open. With these games, instead of the keys not responding temporarily and the mouse getting screwed up by gnome-screensaver after some time (like UT2k4), the mouse simply detaches from the game (Zdoom even detects this and pauses the game for you, presumably because it notices it has lost focus). Click on the game window does not fix it and reattach mouse control. I have to click a different window (or my desktop background; If I'm in fullscreen, I'm out of luck, and I have to ctrl-alt-f1, log in, and kill the game). And selecting a different window doesn't even work the first time, I have to click several times before it does, then I can click back to the game to make it active again.

Bugs like this (and the lack of a fix) make me feel like the only gamer who has touched Ubuntu with anything shorter than a 10 ft pole sometimes. This bug and the inability to use volume controls while a game has mouse control are literally the only two major problems I have with Ubuntu.

I have this bug only with Compiz enabled. If I turn off Compiz, screensaver does not activates when I'm playing SDL games like XMoto.

I just noticed today that this problem also shows up while using KVM/QEMU (current kvm package from ubuntu reps). While running a virtualized system that has control of the mouse, the screensaver doesn't notice any keypresses or mouse input as long as the mouse is grabbed by KVM's SDL window, and starts after 5 minutes. It at least detaches the mouse at the same time properly, so if you move the mouse quickly you can cancel it and click back to KVM. Pretty annoying, especially if I'm in the middle of a task in the VM.

Confirmed on current Jaunty + Compiz running QEMU. In the QEMU case, after escaping the screensaver (which is "Blank screen"), all keyboard input and mouse clicks go into limbo, the mouse pointer moves very slowly, and I cannot un-grab it. I can only get the Gnome desktop back by moving to a VT and killing QEMU cold. This is definitely not good for the guest.

Also confirmed on Jaunty Netbook Remix running Hedgewars. This only dims the screen, and never suspends. Netbook Remix does its own compositing, but does not run Compiz.

Haven't tested without compositing WMs yet.

Compiz 0.8.4 came out recently.

I tested the screensaver problem on karmic with it. All games were fullscreened at my resolution

Wesnoth worked fine
XMoto worked fine
Neverball did not work fine - screensaver kicked me off fullscreen.
Nexuiz worked just fine

I think this bug is fixed because games like xmoto now doesn't activates screensaver but the other games activating are because this other bug:
"Joystick activity does not stop the screensaver "
https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/30378

Are your games activating screensaver using keyboard or joystick?
I am trying to play Secret Maryo Chronicles and screensaver activates using joystick (not this bug).

I played Frozen Bubble with the keyboard.

Sauerbraten works fine with 9.10

This should be fixed in Karmic, as we migrated to the version that is using IDLETIME for detecting session idle-ness (via gnome-session). Please only reopen it if you can recreate the same issue on Karmic or Lucid

I'm running compiz 0.8.4 and I still have the problem I mentioned earlier with the screensaver interrupting QEMU.

I no longer experience this bug with Dosbox (an sdl app) in Lucid.