|Summary:||fullscreen vnc causes xscreensaver to not be unlockable|
|Product:||[Fedora] Fedora||Reporter:||Nils Philippsen <nphilipp>|
|Component:||vnc||Assignee:||Adam Tkac <atkac>|
|Status:||CLOSED WONTFIX||QA Contact:||David Lawrence <dkl>|
|Version:||rawhide||CC:||felix.schwarz, hp, jwz, markmc, ovasik, rvokal, seg, twaugh|
|Fixed In Version:||4.1.1-17||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-01-18 10:19:23 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Nils Philippsen 2003-10-08 11:39:44 UTC
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 11:44:37 UTC
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 12:05:40 UTC
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 18:44:05 UTC
I mean the one on the display running the viewer.
Comment 4 Nils Philippsen 2003-11-12 13:52:12 UTC
Changed product version to Fedora Core 1 as the problem is still there.
Comment 5 Jamie Zawinski 2004-08-15 08:27:52 UTC
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 10:49:49 UTC
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 05:18:11 UTC
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 07:05:37 UTC
> 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 06:02:29 UTC
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 05:58:15 UTC
> 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 17:01:07 UTC
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 17:41:20 UTC
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 17:44:18 UTC
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 13:55:58 UTC
We'll try something similar out in 4.1.1-17.
Comment 15 Tim Waugh 2006-01-05 13:36:24 UTC
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 13:37:45 UTC
*** Bug 177021 has been marked as a duplicate of this bug. ***
Comment 17 Callum Lerwick 2006-05-23 10:39:25 UTC
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 10:00:23 UTC
Created attachment 132359 [details] patch file vnc/unix/vncviewer/CConn.cxx
Comment 19 Adam Tkac 2006-07-13 10:01:28 UTC
Created attachment 132360 [details] patch file vnc/unix/vncviewer/CConn.h
Comment 20 Craig McQueen 2006-08-20 04:24:28 UTC
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 10:24:44 UTC
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 10:19:23 UTC
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