Bug 106552 - fullscreen vnc causes xscreensaver to not be unlockable
fullscreen vnc causes xscreensaver to not be unlockable
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: vnc (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Tkac
David Lawrence
:
: 131428 177021 (view as bug list)
Depends On:
Blocks: FC6Target
  Show dependency treegraph
 
Reported: 2003-10-08 07:39 EDT by Nils Philippsen
Modified: 2013-04-30 19:33 EDT (History)
8 users (show)

See Also:
Fixed In Version: 4.1.1-17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-18 05:19:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch file vnc/unix/vncviewer/CConn.cxx (1.49 KB, patch)
2006-07-13 06:00 EDT, Adam Tkac
no flags Details | Diff
patch file vnc/unix/vncviewer/CConn.h (40 bytes, patch)
2006-07-13 06:01 EDT, Adam Tkac
no flags Details | Diff
switch vnc from fullscreen mode to normal mode before xscreensaver turns on (20.00 KB, patch)
2006-08-23 06:24 EDT, Adam Tkac
no flags Details | Diff

  None (edit)
Description Nils Philippsen 2003-10-08 07:39:44 EDT
Description of problem:

When using vncviewer full-screen and the xscreensaver on the client locks the
screen, you cannot unlock xscreensaver. It seems like vncviewer intercepts the
pressed keys. You also cannot switch back to windowed mode (via F8) because
there isn't any mouse cursor with which to do it (probably "stolen" by
xscreensaver). Typed in password can bee seen in cleartext in open terminal
windows in the VNC session.

Version-Release number of selected component (if applicable):

vnc-4.0-0.beta4.3

How reproducible:

Always

Steps to Reproduce:
1. Configure xscreensaver to lock the screen, not only enable screensaving after
a period of inactivity
2. Start vncviewer full-screen
3. Wait for xscreensaver to lock the screen.
    
Actual results:

As described.

Expected results:

One or more of:
- vncviewer doesn't intercept pressed keys when xscreensaver gets active
- vncviewer switches back to windowed mode after a configurable period of inactivity
- F8 menu can be used with the keyboard alone

Additional info:

Client is Fedora Core/Rawhide, server is Taroon beta
(vnc-server-4.0-0.beta4.1.1, but the server side probably doesn't matter much).
Comment 1 Nils Philippsen 2003-10-08 07:44:37 EDT
Probably another option: Cause xscreensaver not to get active when in
full-screen mode, but this should be configurable.
Comment 2 Tim Waugh 2003-10-08 08:05:40 EDT
Do you mean the xscreensaver on the display running the VNC viewer, or on the
display controlled by the VNC server?
Comment 3 Nils Philippsen 2003-10-09 14:44:05 EDT
I mean the one on the display running the viewer.
Comment 4 Nils Philippsen 2003-11-12 08:52:12 EST
Changed product version to Fedora Core 1 as the problem is still there. 
Comment 5 Jamie Zawinski 2004-08-15 04:27:52 EDT
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.
Comment 6 Mark McLoughlin 2004-09-30 06:49:49 EDT
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?
Comment 7 Havoc Pennington 2004-10-03 01:18:11 EDT
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?
Comment 8 Jamie Zawinski 2004-10-03 03:05:37 EDT
> 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.)
Comment 9 David Masterson 2005-07-23 02:02:29 EDT
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???).
Comment 10 David Masterson 2005-08-23 01:58:15 EDT
> 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.
Comment 11 Steve Parker 2005-09-01 13:01:07 EDT
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.
Comment 12 Dan Allen 2005-09-01 13:41:20 EDT
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??
Comment 13 Dan Allen 2005-09-01 13:44:18 EDT
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.
Comment 14 Tim Waugh 2005-09-06 09:55:58 EDT
We'll try something similar out in 4.1.1-17.
Comment 15 Tim Waugh 2006-01-05 08:36:24 EST
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.
Comment 16 Tim Waugh 2006-01-05 08:37:45 EST
*** Bug 177021 has been marked as a duplicate of this bug. ***
Comment 17 Callum Lerwick 2006-05-23 06:39:25 EDT
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.
Comment 18 Adam Tkac 2006-07-13 06:00:23 EDT
Created attachment 132359 [details]
patch file vnc/unix/vncviewer/CConn.cxx
Comment 19 Adam Tkac 2006-07-13 06:01:28 EDT
Created attachment 132360 [details]
patch file vnc/unix/vncviewer/CConn.h
Comment 20 Craig McQueen 2006-08-20 00:24:28 EDT
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)
Comment 21 Adam Tkac 2006-08-23 06:24:44 EDT
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
Comment 22 Adam Tkac 2007-01-18 05:19:23 EST
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
Comment 23 Ray Strode [halfline] 2007-03-28 12:22:50 EDT
*** Bug 131428 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.