Bug 905935

Created attachment 690410 [details]
DEBUG when screensaver locks

Created attachment 690411 [details]
gconf for screensaver

Created attachment 690412 [details]
spice_debug=1 launch virt viewer

Clicking on switch user, then logging in from gdm works.

Disable COMPIZ and it works.

Downgrade to gnome-screensaver-2.28.3-18.el6_3.1.x86_64 makes no difference,

If you lock the screen with virt-viewer minimized. no issue.
Only when screen saver automatically kicks in.

Same problem using spice instead of virt-viewer?

Is this a spice-gtk bug?

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!

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 ?

Created attachment 691421 [details]
Compiz settings

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.

Created attachment 691600 [details]
flash demo of the issue

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.

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?

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.

Created attachment 692633 [details]
SOS report

Created attachment 692635 [details]
RHEL6 Config.

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.

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

Key seems to be
DISPLAY : SPICE
VIDEO : QXL

Without these settings it works.

RHEL 6.4 DVD.

# INSTALL
# Default partitioning.
# Perform Desktop install.

# Login as user

# ADDITIONAL SOFTWARE
# 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 
[el64]
name=el64
baseurl=file:///"media/RHEL_6.4 x86_64 Disc 1"
enabled=1
gpgcheck=0
EOF

# 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
# Use CDROM
# OS Type Linux. Version RHEL 6.
# Memory 1024, CPU 1
# Storage default 8gb
# SELECT - Customize configuration before install.
# DISPLAY - SPICE
# VIDEO - QXL
# 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.

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.

Hi Ray,
initial tests look good i.e. I can enter the password in the test scenario using the updated gnome-screensaver package.

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.

http://rhn.redhat.com/errata/RHBA-2013-1706.html