Bug 106552

Probably another option: Cause xscreensaver not to get active when in
full-screen mode, but this should be configurable.

Do you mean the xscreensaver on the display running the VNC viewer, or on the
display controlled by the VNC server?

I mean the one on the display running the viewer.

Changed product version to Fedora Core 1 as the problem is still there. 

Presumably this happens because vnc holds the keyboard grabbed for the
entire time that it's running.  That's totally bogus and antisocial
behavior and it ought not do that.

But for what it's worth, as of xscreensaver 4.18, if it can't grab
both the keyboard and mouse, xscreensaver does not blank the screen. 
This means that if you are running vnc or rdesktop or some
antisocially-long-keyboard-grabbing program, xscreensaver will never
lock your screen until that grab is released.

This is still bad, obviously, but perhaps it will confuse people less,
and -- perhaps -- failing to lock at all is less bad than accidentally
typing passwords at the wrong window, or being unable to unlock.

Same issue (well, worse) with rdesktop:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=104713

Note, vncviewer isn't being completely anti-social - when the viewer
is fullscreen, it makes sense for keybindings like Alt-Tab be handled
by the session on the server machine rather than by the local window
manager.

One possible solution might be that could work out some protocol with
the window manager to indicate that all global key grabs should be
dropped for certainfullscreen windows?

Hmm, maybe. Doesn't it also work to just run a lock program on your
remote session, since the vncviewer/rdesktop has the local session
locked, combined with xscreensaver avoiding kicking in while someone
else has the grab?

> vncviewer isn't being completely anti-social

Yes, it is.  Programs that hold the keyboard grabbed for long periods
break everything.  There's absolutely no way to make xscreensaver
function properly in the face of programs that do this horrible thing.

> One possible solution might be that could work out some protocol
> with the window manager to indicate that all global key grabs
> should be dropped for certainfullscreen windows?

That's not a bad idea.  (I turn off all the global keybindings anyway,
because that's the only way to make emacs function.)

This is still a problem with Fedora 4.  I use vncviewer to access (via SSH) my
Windows-XP system at work.  If I am in full-screen mode *AND* the WXP system
turns on its screensaver, the mouse cursor disappears permanently.  However, it
seems that the mouse is still there in some form as, if I hit F8, the vncviewer
menu pops up where (I think) the mouse is (moving the mouse and repeatedly
pushing F8 moves the menu).  At this point, the only thing I can do is
ALT-CTL-F2, login as root, and kill off all the processes on the original login.
 Just killing vncviewer will not bring back the mouse and, without the mouse, I
know of no way to activate the Gnome menu to logout (is there keyboard
shortcuts???).

> One possible solution might be that could work out some protocol with
> the window manager to indicate that all global key grabs should be
> dropped for certainfullscreen windows?

Would another solution be to change vncviewer so that the menu popped up via F8
could be navigated via the keyboard rather than being mouse only?  That way, the
user could exit vncviewer or go to non-fullscreen mode.

I am also experiencing this problem (I use vncviewer to access a Win2000 system
at work) and, for what it's worth, it occurs even though my Win2000 system's
screensaver is disabled.  I have the exact same symptom; oddly enough, you
expect that killing vncviewer would be enough but, once it's dead, neither the
mouse nor keyboard work at all (except for the virtual console switching).  Re:
the menu navigation via keyboard, I am quite certain this is the way it works in
the Windows VNC client, just not in the Linux one.

I really see this as the exact same scenario as watching a movie.  In essence, 
the local client computer is actively using the screen, even though nothing is 
happening to local X events.  mplayer offers a commandline option to prevent 
xscreensaver from running, since xscreensaver's services are not required while 
running this program.  Is it possible to have an xscreensaver switch added to 
the client??

I have found a blog entry that discusses an interim solution:

http://www.kryogenix.org/days/2003/09/09/littleThings

Basically, a deamon is started that keeps feeding xscreensaver with deactivate 
events.

We'll try something similar out in 4.1.1-17.

I had to revert that change because it caused X protocol errors (!).

If someone can come up with a patch that really does work, I'd love to
incorporate it.

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

Wow, this is an old bug. Still having this problem in FC5, with gnome-screensaver.

The screensaver seems to try and kick in, which causes a nasty collision, making
the mouse and keyboard unusable in X. You can move the mouse, but you can't
click or type. I can sometimes get it back by killing vncviewer, then
gnome-screensaver, then metacity, then starting vncviewer again from another
vconsole. But sometimes that doesn't work. No choice but to ctl-alt-backspace
the X server.

Created attachment 132359 [details]
patch file vnc/unix/vncviewer/CConn.cxx

Created attachment 132360 [details]
patch file vnc/unix/vncviewer/CConn.h

Yes I'm having the same problem in FC5, even when the screensaver doesn't have a
password lock. Once the local screensaver activates, I can clear it, but then
the mouse no longer works in the full-screen vncviewer. And the F8 menu also
doesn't work (I can bring up the menu, but can't select any menu item). How
about at least making it possible to select F8 menu items using the keyboard?
(eg press F8, then press Down arrow key then Enter to exit the viewer)

Created attachment 134701 [details]
switch vnc from fullscreen mode to normal mode before xscreensaver turns on

this patch works only with xscreensaver. if you use other else, patch don't
solve the problem. there're three files in tarball - patch (apply to vncviewer)
and two files(copy to vncviewer/). please refer me any problems

It's no way how fix this nasty bug without break any feature. If anyone has idea
how this can be fixed I'm ready discuss proposed patch. Closing WONTFIX

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