Screensaver breaks mouse and keyboard input

I'm experiencing these bug symptoms (clicking does nothing, but cursor is movable, and have to restart X-server).

However, for me it happens when the LOCAL computer goes to sleep (ie, gnome-screensaver kicks in), not when the REMOTE computer goes to sleep. These must be somehow related, since the symptoms are exactly the same.

To recreate my situation, use tsclient to login remotely to some Windows desktop. Set your gnome-screensaver to display in 1 minute. Let it sit to allow the local screensaver to start. After that, you'll notice that the mouse can't click on anything locally or remotely (and things like alt-tab don't work, although in general the keyboard is still responsive, as ctrl-alt-backspace still works to reboot X).

Should I file different bug - "gnome-screensaver with tsclient causes desktop freeze" ?

I have the same problem with local screensaver that causes described symtoms. I've updated the bugs description to something more meaningful..

this is the
bug:

-I start a session
-Open a Terminal Server and connect to my server
-Work with it and all works fine.
-After a long time, we go to my coffe for 15 min. My terminal server is
in the task bar.
-i come back and all is OK.
-I continue with my terminal server
-I go to drink another coffe for 15 min. My terminal server is open and
visible in my desktop.
-I come back and gnome don't response to me. I click all keys and
nothing happends, y move the mouse and the pointer moves(sorry for my
english) but y click in all the monitor and nothing happends.
- Ctrl+alt+f1 works fine
- crtl+alt+f7 and all is equal.
- Finally ctrl+alt+backpace for reboot x server and login again. All
works again.

I have screensaver active (5 min.). I think that if i have the terminal
server open and run screensaver, Gnome (or something) fails.

I hope to be usefull.

This may be a bug in gnome-screensaver, rather than tsclient. I don't know where a patch should be applied.

Anyway, I have a temporary solution. Simply kill the gnome-screensaver process and you will get full mouse control / keyboard control back.

You can kill the process by either a remote SSH terminal, or by hitting CTRL-ALT-F1 and logging into a local terminal session. Once the gnome-screensaver process is killed, switch back to X and all will be well.

Ok, thanks for the tip. I've added gnome-screensaver to this bug :)

More info...

I experienced a different problem (bug 32457 - gnome-screensaver activates while playing SDL games) while using DOSBox, and when I deactivated the screensaver, I lost mouse click and keyboard input, just like with this tsclient problem. The cursor still moved, so the X server wasn't totally frozen, as with tsclient. Only CTRL-ALT-Backspace worked.

Seems to me that this bug is in gnome-screensaver, and is invoked by certain apps like DOSBox (libSDL??) and tsclient (rdesktop).

I'd like to help resolve this bug. Do I need to self compile gnome-screensaver with debug output support, or is there something else I can do? I'm not a strong programmer, just a power user.

Here's the debug from gnome-screensaver. The course of events went like this:

1. Started gnome-screensaver with debug output to file
2. Started tsclient
3. Logged into remote server, then left tsclient window open on desktop
4. Remained idle for 60 seconds (the current config time for gnome-screensaver)
5. Fade began, but didn't totally complete
6. Moved mouse, clicked mouse. No immediate response.
7. Mouse clicks worked inside the tsclient window during this wierd stuck "almost faded" stage.
8. The desktop then returned to normal brightness, screensaver never displaying. Keyboard and mouse are now unresponsive.
9. Explicit X kill with CTRL-ALT-Backspace.

Here's another gnome-screensaver debug output. This time I ran dosbox (which uses libsdl1.2). I experienced the same issue - the fade out doesn't complete, and stuff is clickable during the time when the screen is almost faded. The screensaver didn't fully kick in. This time, however, for some reason I didn't lose mouse/keyboard control.

I thought this log would be useful, because it contains the same "couldn't grab keyboard" errors as the previous log with tsclient.

Seemingly, this isn't related to tsclient, only gnome-screensaver.

Comments in bug #34707 (now marked duplicate of bug #32457) reference this issue. Seems that another libsdl game, ppracer, can trigger the input problem.

We're dealing with two distinctly separate but seemingly related issues, both of which point fingers at gnome-screensaver.

1. (bug #32457) When using libsdl apps (and possibly others), gnome-screensaver plays dumb and can't detect activity.

2. (this bug) After deactivating gnome-screensaver, with certain apps open on screen (libsdl apps, tsclient, etc.), the inputs are locked, giving the impression of an X session freeze, which is a big deal to many users.

What we need now is to get feedback on which apps are affected by the locked input symptoms. The gnome-screensaver folks are hard to budge, so bringing lots of evidence to support the case is critical.

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 an SDL windowed app, an SDL fullscreen app, a tsclient windowed app, and a tsclient fullscreen app. In all cases, whenever the screensaver activated, I regained full control once the screensaver was deactived.

I'm requesting that others further test this patch against this bug.

This also appears to have fixed bug #32457.

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.