Bug 1485968

Summary: spice display unresponsive after host and VM sleep: GSpice-WARNING **: keyboard grab failed 1
Product: [Fedora] Fedora Reporter: Louis van Dyk <louis>
Component: gtk3Assignee: Matthias Clasen <mclasen>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 28CC: alciregi, alon, berrange, cfergeau, cosimo.cecchi, crobinso, danielsun3164, fmuellner, ganguin, hdegoede, jcfaracco, louis, marcandre.lureau, mclasen, oserytsan, otaylor, pgozart, robinlee.sysu, sandmann, victortoso
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-05-28 22:13:08 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:
Attachments:
Description Flags
virt-manager --debug
none
virsh dumpxml Win8.1
none
/var/log/libvirt/qemu/Win8.1.log none

Description Louis van Dyk 2017-08-28 15:06:26 UTC
Description of problem:
Since upgrading to Fedora 26 I have noticed the following ...
I open my Windows 8.1 guest.  While I am working in it all is fine, but if I don't do anything in it for a while (e.g. I am on a Skype call just chatting, or I use other windows in Fedora, ignoring the Guest, then when I click back to the Guest window, the mouse moves over it, but nothing updates on the screen.  (At some rare times it might be black aka screensaver.)  The audio is still working as my Skype chats are still ongoing. The only thing I can do is close the guest GUI and then immediately re-open it in Virt-Manager.  Then everything is working 100% again.  

I upgraded to the Win 8.1 drivers for VIRTIO 141, but this didn't help either.


Version-Release number of selected component (if applicable):
libvirt-3.2.1-4.fc26.x86_64
libvirt-python-3.2.0-1.fc26.x86_64
python2-virtkey-0.63.0-3.fc26.x86_64
virt-install-1.4.2-1.fc26.noarch
virtio-win-0.1.141-1.noarch
virt-manager-1.4.2-1.fc26.noarch
virt-manager-common-1.4.2-1.fc26.noarch
.... amongst others

How reproducible:
As described, and it does it regularly.  I'm just not sure of the time window involved.

Steps to Reproduce:
1. Boot guest.  Working in it, maybe start a call.
2. Do nothing in the Guest for a time.
3. When accessing the Guest, the screen is frozen (although audio is still working), and you have to close and reopen the Guest.

Actual results:


Expected results:
It should not freeze.  It didn't freeze on Fedora 25.


Additional info:

Comment 1 Cole Robinson 2017-08-30 18:05:12 UTC
Thanks for the report. Please provide the VM XML: sudo virsh dumpxml VM-NAME

Can you also try reproducing by launching 'virt-manager --debug' from a terminal, and when you get the freeze, grab all the output from the terminal and attach it to this bug, I'm curious if there's any spice errors. Also provide /var/log/libvirt/qemu/VM-NAME.log after you hit an error, there might be qemu/spice errors in there

Comment 2 Louis van Dyk 2017-09-07 14:26:32 UTC
Created attachment 1323190 [details]
virt-manager --debug

Comment 3 Louis van Dyk 2017-09-07 14:27:18 UTC
Created attachment 1323202 [details]
virsh dumpxml Win8.1

Comment 4 Louis van Dyk 2017-09-07 14:27:59 UTC
Created attachment 1323203 [details]
/var/log/libvirt/qemu/Win8.1.log

Comment 5 Louis van Dyk 2017-09-07 14:30:58 UTC
EVENTUALLY it seems to have done it again.  This time though, I noticed that the time was still moving forward.  I am not 100% sure if that was the case previously.  The mouse and keyboard were not grabbed -- the mouse pointer was black, and pressing the Windows Key or ALT-F2 had Gnome responding.  Also, the end of the debug output of virt-manager showed that they keyboard was not grabbed.

I will keep running it in this fashion to see if it does it again.

Comment 6 Cole Robinson 2017-09-11 19:21:07 UTC
Thanks for the info. That message:

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

The 1 there is GDK_GRAB_ALREADY_GRABBED meaning some other client already has focus. Not sure what that specifically means here.

Are you using gnome-shell or some other desktop environment?

Comment 7 Louis van Dyk 2017-09-12 12:13:46 UTC
Yes, I run Gnome Shell.  But I have the NVIDIA drivers from Negativo17.org installed, which in my limited understanding means that I don't think I run Wayland.

I do have weird problems with Gnome, where it just doesn't respond.  The mouse moves all over the screen, but nothing responds.  I usually then switch to another text console, log in as root, and run killall -3 gnome-shell which most times sorts it out.  I have been experiencing THAT for many years now - always hoping that the next release of Fedora would fix it.  I have a feeling that it's tied to Evolution because most of the times that it freezes is when I have done something in Evolution.

Standard applications I have open are:
- gnome terminal running SABnzbd and SickBeard.
- Firefox
- Evolution
- virt-manager
- occasionally LibreOffice Calc

Let me know how else I can be more informative.

Comment 8 Cole Robinson 2017-09-12 15:41:26 UTC
How often do you get the gnome problems? IMO it would be interesting to try non-nvidia drivers and see if either issue persists, nvidia drivers cause all sorts of weird issues. I realize that's probably not a suitable solution for you but it could identify the culprit

Comment 9 Louis van Dyk 2017-09-28 08:57:54 UTC
Hi Cole. Sorry for being silent so long. I've not changed back to the nouveau drivers because the unresponsive Gnome thing has been happening on my laptop for years too, and it runs an Intel graphics driver.  If you insist on it though, I will make a plan to test it out (and not play any Steam games) LOL.

However, I can report back on what I have noticed.  EVERY time it happens, the debug log shows:
(virt-manager:20140): GSpice-WARNING **: keyboard grab failed 1

I can go days without it happening.  It happens much more often when I am on a "Skype for Business" voice call. But not always.  But the one time I notice it happening almost consisitently is once the "screensaver" has kicked in.  The screen begins to fade to black, and often (but not always) this message appears in the debug output.

My guess is then that it's most likely to do with the screen lock.

Comment 10 Louis van Dyk 2017-09-28 23:20:13 UTC
I have just noticed on:
https://www.spice-space.org/download/windows/vdagent/
that vdagent 0.9.0 is out. I have been running 0.7.3 until now. I will report back if that makes any difference.

Comment 11 Louis van Dyk 2017-09-29 09:42:22 UTC
Nope.  Didn't help.  I was text chatting on Skype for Business.  Had to leave for about an hour.  When I came back and unlocked Gnome, the Windows screen was there but the moment I moved the mouse onto the screen it went black, and the mouse was not working in Windows (i.e. it had the black Gnome pointer, not the white Windows pointer.  The GSpice message came up again too.

Comment 12 ganguin 2017-10-04 08:36:57 UTC
I have exactly the same issue on Win10 guest (on debian, with gnome wayland and gnome-shell)

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

As Louis says, it seems related to the screensaver. I am 100% sure but it seems only to happen when both host and VM start the screensaver

Comment 13 Louis van Dyk 2017-10-17 11:10:23 UTC
I have changed my login screen to "Gnome" instead of "Gnome Xorg".  That still has not helped.

In the freeze that just happened now (and it doesn't ALWAYS happen), I had Seamonkey open on an animated web page, and I had Skype for Business open.  I left the room for 20 minutes, so the Gnome screensaver kicked in.  I unlocked Gnome, and saw the VM screen.
- the background of the constantly playing movie clip would update once every 20 or 30 seconds.
- the mouse pointer stayed BLACK (meaning it was working on Gnome, and not on Windows, when it is white).
- pressing the windows key had Gnome respond, not Windows.
- the DEBUG log again had showed
(virt-manager:9683): GSpice-WARNING **: keyboard grab failed 1
- although I wasn't playing sound this time, at other times when it freezes, the audio continues working without a hitch

When I closed the VM's screen and immediately re-opened it, the video on the web page played smoothly, and I could again have the mouse be active inside the VM.

Comment 14 Cole Robinson 2017-11-25 20:40:07 UTC
Okay I can reproduce. Used a win10 VM, set VM display to turn off after 1 minute, set host f27 gnome-shell display to turn off after 2 minutes, give mouse/keyboard focus to the VM, wait until host display turns off, unlock host, and the VM display is unresponsive.

verified with both virt-manager and virt-viewer. Also verified that virt-viewer+vnc doesn't have this issue, so I'm guessing spice is the culprit

Comment 15 Cole Robinson 2017-11-25 20:49:36 UTC
VM going to sleep doesn't matter, just seems to depend on the host locking the display while the VM has mouse/keyboard focus

Comment 16 Robin Lee 2017-12-27 01:33:43 UTC
Met the same issue with recent updates. Never met this issue before.
spice-gtk3-0.34-1.fc26.x86_64

I have two monitors and the remote-viewer use one of it.

Comment 17 Robin Lee 2017-12-27 01:34:33 UTC
Leaving/entering full screen will get the keyboard/mouse functioning again.

Comment 18 Robin Lee 2017-12-27 07:02:17 UTC
Switching to VM details tab and back to console tab will also get the keyboard/mouse functioning again.

Comment 19 Robin Lee 2018-01-09 02:45:16 UTC
Never an issue if first focus on the non-spice part of virt-manager window, like window title, menu bar, then focus onto the spice area.

Comment 20 Christophe Fergeau 2018-01-09 12:59:29 UTC
(In reply to Cole Robinson from comment #14)
> Okay I can reproduce. Used a win10 VM, set VM display to turn off after 1
> minute, set host f27 gnome-shell display to turn off after 2 minutes, give
> mouse/keyboard focus to the VM, wait until host display turns off, unlock
> host, and the VM display is unresponsive.
> 
> verified with both virt-manager and virt-viewer. Also verified that
> virt-viewer+vnc doesn't have this issue, so I'm guessing spice is the culprit

Is this 100% reproducible for you? I managed to reproduce once, but was not successful to hit this a 2nd time.

Comment 21 Cole Robinson 2018-01-30 18:11:03 UTC
(In reply to Christophe Fergeau from comment #20)
> Is this 100% reproducible for you? I managed to reproduce once, but was not
> successful to hit this a 2nd time.

I just reproduced it 3/3 times with virt-manager and 1/1 times with virt-viewer. This is with the comment #14 method. Comment #15 didn't work the one time I tried it so that may be wrong

Comment 22 Cole Robinson 2018-03-27 18:52:59 UTC
*** Bug 1560726 has been marked as a duplicate of this bug. ***

Comment 23 Marc-Andre Lureau 2018-04-30 14:29:12 UTC
After the grab failed (when screen dims after timeout and starts to lock itself), spice-gtk widget never receives the enter-notify event again, and thus will no longer attempt to take the grab.

This seems like a gtk+ or gnome-shell/mutter bug (something changed as I remember the screen didn't lock itself when the grab was taken before), reassigning.

Comment 24 Julio Faracco 2018-05-02 14:16:04 UTC
A possible solution for me was change the field 'grab-keyboard' to false into gsettings. I didn't discovered what are the consequences yet (I read the virt-manager code, but it is possible related to Spice anyway) but, at least, I can lock my screen without the GSpice warning or weird Spice behaviours.

Comment 26 Victor Toso 2018-05-22 07:20:13 UTC
One can try the scratch-build at [0] which includes the proposed patch [1]

[0] https://koji.fedoraproject.org/koji/taskinfo?taskID=27121977

[1] https://lists.freedesktop.org/archives/spice-devel/2018-May/043607.html

Comment 27 Victor Toso 2018-05-25 09:55:52 UTC
This is likely to be fixed by next 3.22 release by 

https://gitlab.gnome.org/GNOME/gtk/commit/c926b28d965dbae90b17d404d2c6d1e031a6f006

and possibly

https://gitlab.gnome.org/GNOME/gtk/merge_requests/166

Comment 28 Louis van Dyk 2018-08-22 13:20:00 UTC
The condition is still occurring.  Not sure why Fedora 28 which is ACTIVE is not going to have gtk 3.22 updated if I read the comments on 
https://gitlab.gnome.org/GNOME/gtk/merge_requests/166
correctly.

I have 
gtk3-3.22.30-1.fc28.i686
gtk3-3.22.30-1.fc28.x86_64
installed.

Comment 29 Victor Toso 2018-08-22 14:12:34 UTC
Thanks for bringing this up again Louis.

Can some from Gtk3 backport this fix to Fedora at least?

Comment 30 Ben Cotton 2019-05-02 21:02:43 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 31 Ben Cotton 2019-05-28 22:13:08 UTC
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.