Bug 1571422

Summary: KVM is no longer responding to mouse & keyboard after lock/unlock
Product: Red Hat Enterprise Linux 7 Reporter: Paul Gozart <pgozart>
Component: gtk3Assignee: Benjamin Otte <otte>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: high    
Version: 7.5CC: cfergeau, dblechte, djasa, jkoten, klember, mclasen, ofourdan, otte, pgozart, tpelka, victortoso
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: gtk3-3.22.30-3.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-30 10:26:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Paul Gozart 2018-04-24 18:27:27 UTC
Description of problem:
The KVM will not respond to mouse or keyboard after lock/unlock when running and opening KVMs from virt-manager on RHEL7.5.  Using remote-viewer spice://localhost:5900 there is no such issue.  Customer tested with their corporate build of RHEL 7.5 and different RHEL and Windows KVMs as well as a vanilla RHEL 7.5 host with a RHEL 7.5 guest.


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


How reproducible:
Repeatedly


Steps to Reproduce:
1. Start and open KVM from virt-manager
2. Wait until the desktop of the guest is ready
3. Use the menu in upper right corner of the desktop of the host to lock the screen
4. Wait until it is locked and unlock the screen again
5. The KVM will not respond to mouse or keyboard  


Actual results:
The KVM will not respond to mouse or keyboard after lock/unlock


Expected results:
The KVM will respond to mouse or keyboard after lock/unlock


Additional info:

Comment 5 Victor Toso 2018-04-26 11:50:54 UTC
I'm able to reproduce reliably with both virt-manager and remote-viewer. Seems that the window being maximized is important.

virt-manager outputs:

(virt-manager:11648): GSpice-WARNING **: keyboard grab failed 1

Which is similar to Bug 1485968 (upstream)

Comment 6 Victor Toso 2018-04-26 11:55:36 UTC
A simple workaround is to switch to 'Details' tab and back to 'Graphical console' tab.

Comment 9 Victor Toso 2018-05-16 15:31:15 UTC
Please refer to Marc-André comment at: https://bugzilla.redhat.com/show_bug.cgi?id=1485968#c23

In spice-gtk, the problem is triggered with GTK 3.20 and up as we switched to gdk_seat_grab() and gdk_seat_ungrab() for keyboard and pointer grab/ungrab.

The value that is emitted from in "keyboard grab failed 1" is GDK_GRAB_ALREADY_GRABBED from gdk_seat_grab() and it happens about the moment we try to Lock the screen.

I guess that when we succeed in locking the screen, it will hold the keyboard but a focus-in-event will also happen in remote-viewer which then tries to grab the keyboard and fails.

We could be using the API wrong, Pavel opened a bug to get advice in the past without success: https://bugzilla.gnome.org/show_bug.cgi?id=780133

Note that I could not reproduce the problem when switching back to old API. Moving to GTK+, suggestions?

Comment 15 Victor Toso 2018-05-24 16:06:20 UTC
I have a possible fix submitted at
https://gitlab.gnome.org/GNOME/gtk/merge_requests/163

Comment 22 Kalev Lember 2018-09-05 11:29:30 UTC
Looks like the gtk3 -3 package somehow ended up getting dropped from the advisory. I've added it back now.

Comment 23 Victor Toso 2018-09-06 11:13:15 UTC
Many thanks Kalev!

Comment 25 David Jaša 2018-09-13 14:03:20 UTC
Interesting, I can't reproduce the issue in 7.6 with windows 10 guest:
- gtk3-3.22.30-2.el7.x86_64 (so one rev before the fix)
- spice-gtk3-0.35-2.el7.x86_64
- virt-manager-1.5.0-1.el7.noarch

Comment 28 errata-xmlrpc 2018-10-30 10:26:16 UTC
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.

https://access.redhat.com/errata/RHSA-2018:3140