Screensaver breaks mouse and keyboard input

Bug #48108 reported by david thompson
Affects Status Importance Assigned to Milestone
gnome-screensaver (Ubuntu)
tsclient (Ubuntu)

Bug Description

I will try to gather more info than this, but here is what happens:

When I remote into Win2K3 Server with RDP the session works fine until the 2k3 server locks itself (goes to ctrl-alt-del). At this point my mouse is moveable, but clicking on anything does nothing. The keyboard still works and everything else seems normal, but I have to restart the X-server to regain the ability to 'click' on anything.

Other users experience the opposite problem - local screensaver causes the same symtoms as described above...

This is apparently related to gnome-screensaver, since killing gnome-screensaver resolves the problem.

Revision history for this message
Philip Cain (philipacamaniac) wrote :

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" ?

Revision history for this message
Mikkel Høgh (mikl) wrote : Re: PC sleeps makes breaks mouse input and hotkeys

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

description: updated
Changed in tsclient:
importance: Medium → High
status: Unconfirmed → Confirmed
Revision history for this message
perriman (chuchiperriman) wrote :

this is the

-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.

Revision history for this message
Philip Cain (philipacamaniac) wrote :

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.

Revision history for this message
Mikkel Høgh (mikl) wrote :

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

Changed in gnome-screensaver:
status: Unconfirmed → Confirmed
description: updated
Mikkel Høgh (mikl)
Changed in tsclient:
status: Confirmed → Needs Info
Revision history for this message
Philip Cain (philipacamaniac) wrote :

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.

Revision history for this message
Philip Cain (philipacamaniac) wrote : Debug output from gnome-screensaver

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.

Revision history for this message
Philip Cain (philipacamaniac) wrote : Debug output from gnome-screensaver (during dosbox/libsdl session)

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.

Revision history for this message
Mikkel Høgh (mikl) wrote :

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

Changed in tsclient:
status: Needs Info → Rejected
Revision history for this message
Philip Cain (philipacamaniac) wrote :

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.

Revision history for this message
Philip Cain (philipacamaniac) wrote : Patch from upstream

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.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

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

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

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.

Changed in gnome-screensaver:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers