Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

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 16 Victor Toso 2018-05-25 10:05:14 UTC 
Should be fixed by: https://gitlab.gnome.org/GNOME/gtk/commit/c926b28d965dbae90b17d404d2c6d

and

https://gitlab.gnome.org/GNOME/gtk/merge_requests/166
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