Bug 905935 - virt-viewer - unable to enter gnome-screensaver password
virt-viewer - unable to enter gnome-screensaver password
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gnome-screensaver (Show other bugs)
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Ray Strode [halfline]
Desktop QE
: ZStream
Depends On:
Blocks: 994864 994868
  Show dependency treegraph
Reported: 2013-01-30 09:13 EST by Grant Williamson
Modified: 2013-11-21 18:30 EST (History)
10 users (show)

See Also:
Fixed In Version: gnome-screensaver-2.28.3-25.el6
Doc Type: Bug Fix
Doc Text:
* Previously, when using virt-manager, virt-viewer, and spice-xpi applications, users were unable to enter the gnome-screensaver password after the screen saver started. This happened only when the VM system used the Compiz composting window manager. After users released the mouse cursor, then pressed a key to enter a password, the dialog did not accept any input. This happened due to incorrect assignment of window focus to applications that did not drop their keyboard grab. With this update, window focus is now properly assigned to the correct place, and attempts to enter the gnome-screensaver password no longer fail in the described scenario.
Story Points: ---
Clone Of:
Last Closed: 2013-11-21 18:30:21 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
DEBUG when screensaver locks (32.91 KB, text/x-log)
2013-01-30 09:45 EST, Grant Williamson
no flags Details
gconf for screensaver (20.05 KB, text/xml)
2013-01-30 09:46 EST, Grant Williamson
no flags Details
spice_debug=1 launch virt viewer (57.08 KB, text/x-log)
2013-01-30 09:54 EST, Grant Williamson
no flags Details
Compiz settings (16.15 KB, text/xml)
2013-02-01 02:34 EST, Grant Williamson
no flags Details
flash demo of the issue (2.42 MB, application/x-shockwave-flash)
2013-02-01 09:32 EST, Grant Williamson
no flags Details
SOS report (662.12 KB, application/x-xz)
2013-02-04 02:29 EST, Grant Williamson
no flags Details
RHEL6 Config. (3.64 KB, text/xml)
2013-02-04 02:30 EST, Grant Williamson
no flags Details

  None (edit)
Description Grant Williamson 2013-01-30 09:13:02 EST
Description of problem:
Launch a Windows guest user virt-viewer.
Ensure virt-viewer has mouse focus.
Wait 20 minutes. Release mouse cursor.
Gnome Screensaver will lock.
Hit space and try to enter password, unable to enter password.
Dialog accepts no input.

Version-Release number of selected component (if applicable):
kernel 2.6.32-355.el6.x86_64
Comment 2 Grant Williamson 2013-01-30 09:45:27 EST
Created attachment 690410 [details]
DEBUG when screensaver locks
Comment 3 Grant Williamson 2013-01-30 09:46:03 EST
Created attachment 690411 [details]
gconf for screensaver
Comment 4 Grant Williamson 2013-01-30 09:54:26 EST
Created attachment 690412 [details]
spice_debug=1 launch virt viewer
Comment 5 Grant Williamson 2013-01-30 09:55:36 EST
Clicking on switch user, then logging in from gdm works.
Comment 6 Grant Williamson 2013-01-30 10:04:40 EST
Disable COMPIZ and it works.
Comment 7 Grant Williamson 2013-01-30 10:08:52 EST
Downgrade to gnome-screensaver-2.28.3-18.el6_3.1.x86_64 makes no difference,
Comment 8 Grant Williamson 2013-01-30 10:16:03 EST
If you lock the screen with virt-viewer minimized. no issue.
Only when screen saver automatically kicks in.
Comment 9 Grant Williamson 2013-01-30 10:24:02 EST
Same problem using spice instead of virt-viewer?

Is this a spice-gtk bug?
Comment 12 Ray Strode [halfline] 2013-01-31 17:36:04 EST
So in the screensaver log I see, the system has noticed it's idle:

[watcher_idle_notice_cb] gs-monitor.c:125 (09:40:31):	 Idle notice signal detected: 1

and then the screensaver daemon tries to take control of the keyboard and mouse so it can begin the fade down that lets users cancel the lock:

[gs_grab_grab_offscreen] gs-grab-x11.c:548 (09:40:31):	 Grabbing an offscreen window

It's unable to grab the keyboard though (presumably since virt-viewer has a grab):

[gs_grab_grab_offscreen] gs-grab-x11.c:548 (09:40:31):	 Grabbing an offscreen window

So then it tries removing the focus from the focused app (virt-viewer) in the hopes it will coax the app into dropping its grab:

[gs_grab_nuke_focus] gs-grab-x11.c:410 (09:40:35):	 Nuking focus

Didn't help though:

[gs_grab_get_keyboard] gs-grab-x11.c:187 (09:40:35):	 Couldn't grab keyboard!  (AlreadyGrabbed)

Finally gives up, so it won't do the fade out:

[watcher_idle_notice_cb] gs-monitor.c:138 (09:40:39):	 Could not grab the keyboard so not performing idle warning fade-out

Then it waits 10 seconds (which would normally be when the fade down happens) and starts to activate the screensaver:

[listener_check_activation] gs-listener-dbus.c:325 (09:40:49):	 Trying to activate

It then tries to grab the keyboard again:

[gs_grab_get_keyboard] gs-grab-x11.c:172 (09:40:49):	 Grabbing keyboard widget=B9

Success! presumably, virt-viewer has released it's grab at this point from user intervention. It now tries to grab the mouse:

[gs_grab_get_mouse] gs-grab-x11.c:208 (09:40:49):	 Grabbing mouse widget=B9

Also, a succcess.  Since it couldn't fade out before, it's going to do a quick 1 second fade out now:

[gs_manager_activate] gs-manager.c:1916 (09:40:49):	 fading out

And then it maps the screensaver window:

[fade_done_cb] gs-manager.c:1877 (09:40:50):	 fade completed, showing windows

Now it moves the grabs from the root window to a screensaver specific window:

[gs_grab_move_keyboard] gs-grab-x11.c:368 (09:40:50):	 Moving keyboard grab from B9 to E00048
[gs_grab_move_mouse] gs-grab-x11.c:312 (09:40:50):	 Moving pointer grab from B9 to E00048

It would now start a screensaver except it's configured for blank-screen:

[gs_job_start] gs-job.c:435 (09:40:50):	 starting job
[gs_job_start] gs-job.c:450 (09:40:50):	 No command set for job.

10 more seconds go by, and there must have been some user activity because:

[find_window_at_usable_monitor] gs-manager.c:1222 (09:41:02):	 Requesting unlock for screen 0

So we show the unlock dialog:
[gs_window_request_unlock] gs-window-x11.c:1670 (09:41:02):	 Requesting unlock

we drop the mouse grab since we need the mouse to work in the unlock dialog that we just popped up:

[gs_grab_release_mouse] gs-grab-x11.c:271 (09:41:02):	 Ungrabbing pointer

okay unlock dialog is up and it asks for a password:

[popup_dialog] gs-window-x11.c:1606 (09:41:02):	 Popping up dialog
[error_watch] gs-window-x11.c:985 (09:41:02):	 command error output: [gs_lock_plug_enable_prompt] gs-lock-plug.c:1111 (09:41:02):	 Setting prompt to: Password:

Use switched VT (probably from clicking switch user button):

[listener_dbus_handle_system_message] gs-listener-dbus.c:1460 (09:41:08):	 ConsoleKit notified ActiveChanged 1

system unlocked session (probably from user switching):

[listener_dbus_handle_system_message] gs-listener-dbus.c:1431 (09:41:15):	 Console kit requested session unlock

system is unlocked:

[gs_grab_release] gs-grab-x11.c:425 (09:41:15):	 Releasing all grabs

screensaver window is hidden:

[window_unmap_cb] gs-manager.c:1349 (09:41:15):	 window unmapped!
Comment 13 Ray Strode [halfline] 2013-01-31 17:47:07 EST
So the interesting thing here, is gnome-screensaver does have control of the keyboard:

- According to comment 0 the space bar causes the unlock dialog to show up.  
- The attached log shows gnome-screensaver is able to get a keyboard grab.

One theory would be that focus is getting placed on the wrong window within gnome -screensaver. gnome-screensaver's keyboard grab is in place with owner_events=FALSE, though so that shouldn't be possible.

Another theory is keyboard focus within the toplevel is going to the wrong child.

Grant, if you hit the escape key does the dialog go away?  if you hit space bar again, does it come back? Is focus correct after those steps?

I've been unable to reproduce this problem. If I install compiz, run compiz --replace, and try to follow the same steps using virt-viewer, remote-viewer, or spicec, it works every time.

I would appreciate if you could attach the output of gconftool-2 -R /apps/compiz ?
Comment 14 Grant Williamson 2013-02-01 02:34:37 EST
Created attachment 691421 [details]
Compiz settings
Comment 15 Grant Williamson 2013-02-01 02:46:10 EST
When the screen blanks - pressing space bar shows the dialog.
HIT ESCAPE - dialog does not go away.
Only thing to do is to click switch user.
Comment 16 Grant Williamson 2013-02-01 09:32:28 EST
Created attachment 691600 [details]
flash demo of the issue
Comment 17 Grant Williamson 2013-02-01 09:33:42 EST
Retested with 6.4 snapshot 5 installed off DVD.
No additional IBM customizations were made.
Np additional IBM software was installed on Host.

Check flash demo, please.
Comment 18 Ray Strode [halfline] 2013-02-01 17:07:52 EST
Grant, so to be sure. the steps you took in your video are:

1) wait until the screen would lock, but doesn't because the input belongs to virt-viewer
2) hit "ctrl+alt" to release pointer
3) wait for screen to lock
4) hit space bar
5) try to type and realize you're unable to and then resort to user switching

I'm a little confused because in my testing the window says "(Press Ctrl+Alt to release pointer)" before the pointer is released.  After pressing ctrl+alt the keyboard grab doesn't get removed until I move my mouse outside the bounds of the window.  In your video I don't see that text, and I don't see you move the mouse outside the bounds of the window.

If my steps above are wrong, can you correct them?

Also, if you hit a different key instead of spacebar to summon the unlock dialog ("Say the letter 'a') does a bullet appear in the entry?
Comment 19 Grant Williamson 2013-02-04 02:29:05 EST
Maybe that is the issue, I am not seeing the virt-viewer grabbing the mouse.

I have no xorg.conf file.
No additional packages added.

Let me add guest config and sosreport.
Comment 20 Grant Williamson 2013-02-04 02:29:40 EST
Created attachment 692633 [details]
SOS report
Comment 21 Grant Williamson 2013-02-04 02:30:35 EST
Created attachment 692635 [details]
RHEL6 Config.
Comment 22 Grant Williamson 2013-02-04 07:31:07 EST
I can click in the windows at grub and it says "(Press Ctrl+Alt to release pointer)" but when guest starts booting i.e. plymouth kicks in it stops the grab.
Comment 23 Grant Williamson 2013-02-04 08:38:46 EST
"Also, if you hit a different key instead of spacebar to summon the unlock dialog ("Say the letter 'a') does a bullet appear in the entry?" - makes no difference.
Comment 24 Grant Williamson 2013-02-04 13:12:47 EST
Key seems to be

Without these settings it works.
Comment 25 Grant Williamson 2013-02-05 05:14:11 EST

# Default partitioning.
# Perform Desktop install.

# Login as user

# As root disable plugins in /etc/yum.conf 
# i.e. plugins=0

# Use DVD as repository.
cat >> EOF > /etc/yumrepos.d/el6.4-dvd.repo 
baseurl=file:///"media/RHEL_6.4 x86_64 Disc 1"

# As root install additional packages after install has completed.
yum install virt-viewer qemu-kvm qemu-img virt-manager libvirt -y
# Enable compiz, system preferences. desktop effects.
# Change screensaver to lock screen after 1 minute
# restart

# As user start virt-manager, create a new guest, call it TEST.
# Local install media
# OS Type Linux. Version RHEL 6.
# Memory 1024, CPU 1
# Storage default 8gb
# SELECT - Customize configuration before install.
# Perform Desktop install.
# Shutdown when guest has completed.

#Start guest, as user type
virsh -c qemu:///system start TEST
virt-viewer -c qemu:///system TEST

Wait till guest has booted, maximize window(not full screen).
Click mouse in centre of window and leave till screen locks.
When fully dimmed and locked, press keyboard and try and enter password.
Comment 27 Ray Strode [halfline] 2013-02-05 14:09:11 EST
Hey Grant,

I was able to connect with Marian and debug remotely somewhat.

gnome-screensaver has some code borrowed from xscreensaver to try to get applications to drop keyboard grabs at lock time.

It does this by first trying to get a keyboard grab, and if unsuccessful, it tries to unfocus the currently focused window (in the hopes that the currently focused application will notice it's lost focus and then willfully drop its grab).  It does that with this code:

XSetInputFocus (GDK_DISPLAY (), None, RevertToNone, CurrentTime);

For reasons I haven't quite figured out yet, after this call, in some scenarios (like yours) focus never gets assigned to the correct place following this call.

I've put up a scratch build at http://people.redhat.com/~rstrode/gnome-screensaver-2.28.3-23.el6.movefocus.x86_64.rpm that:

1) removes the unfocus call above
2) replaces that call with a call to explicitly set focus on the desired grab window before acquiring the grab

These changes should meet the spirit of the original xscreensaver code, but side step the focus dropping issue.  I'd appreciate feedback on if those scratch packages work around your issue.

I'll update again when I've got a more clear picture on what's going on.
Comment 29 Grant Williamson 2013-02-06 01:51:47 EST
Hi Ray,
initial tests look good i.e. I can enter the password in the test scenario using the updated gnome-screensaver package.
Comment 41 errata-xmlrpc 2013-11-21 18:30:21 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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