Bug 1611706

Summary: virt-viewer 6.0 frequently stops responding to mouse scroll-wheel input (usually when full-screen)
Product: [Fedora] Fedora Reporter: Robert <redhat-bz>
Component: virt-viewerAssignee: Daniel Berrangé <berrange>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 28CC: berrange, cfergeau, fidencio, marcandre.lureau, redhat-bz, victortoso
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-08-24 13:16:00 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
spice-debug log of brief virt-viewer session effected by loss of scroll wheel input none

Description Robert 2018-08-02 16:38:36 UTC 
Description of problem:
After regular system update, I find that recently (for a few weeks? maybe a month?) the scroll wheel will regularly stop working in my VMs.

Version-Release number of selected component (if applicable):
virt-viewer-6.0-4.fc28.x86_64

How reproducible:
90%

Steps to Reproduce:
1. Use a VM in a scroll-intensive workflow (such as facebook/twitter/rss/email/reddit feeds)

Actual results:
After a while, with no obvious cause that I can perceive, the scrollwheel will no longer work.

Expected results:
The scroll-wheel on the mouse should send the appropriate events to the guest operating system whenever it is connected & the mouse is over the virt-viewer window.

Additional info:
Whenever the scroll-wheel stops working, I find that I can workaround it by toggling the fullscreen option (*usually* I find myself un-fullscreening the app, but ocasionally, I think, the other way around), or switching to another virtual desktop (so kwin shuffles the x11 window about).
Comment 1 Robert 2018-08-02 17:14:54 UTC 
I thought I would add that I also have two monitors, so (for me) "full screen" does not imply that the mouse cursor might leave & return... could be an important detail.
Comment 2 Victor Toso 2018-08-03 09:42:07 UTC 
- The remote-viewer client is running on KDE or GNOME? Under X11 or Wayland?
- Does it take too long to reproduce?
- Could you please provide the log from your client using --spice-debug which includes the situation that the scroll stopped working?

I tried to reproduce for about 5 minutes on X11/GNOME F28 client with X11/GNOME F28 guest, nothing so far.

Cheers,
Comment 3 Robert 2018-08-03 15:07:32 UTC 
Created attachment 1473028 [details]
spice-debug log of brief virt-viewer session effected by loss of scroll wheel input


* I'm running under kde/x11
* I don't think it is time dependent. Sometimes the scroll wheel works for a long time, and other times it abruptly stops working shortly after entering a virt-viewer window. Now I get the impression it is more like a co-incidence of inputs, or something...
* I've attached such a log where (1) the interaction time is short, (2) the scroll wheel stopped working, and (3) upon noticing it stop working, I 'leave' the window to cut the log file.

In case it saves you a bit of time, I *think* these are the messages you are looking for (which seem to replace the 'scroll_event' messages?):

'''
decode-glz.c:352 decode_header: 758x48, id 451, ref 421
decode-glz.c:352 decode_header: 758x48, id 452, ref 421
decode-glz.c:352 decode_header: 758x48, id 453, ref 421
decode-glz.c:352 decode_header: 758x48, id 454, ref 421
decode-glz.c:352 decode_header: 758x48, id 455, ref 422
decode-glz.c:352 decode_header: 758x48, id 456, ref 422
decode-glz.c:352 decode_header: 758x48, id 457, ref 422
decode-glz.c:352 decode_header: 758x48, id 458, ref 422
'''

NB: I have recently found that... *often*... all that is needed to "reset" virt-viewer from this state (i.e. work around the issue) is cursor out-then-back-into the viewer window...
Comment 4 Robert 2018-08-24 13:16:00 UTC 
I am increasingly convinced that this is actually a kwin problem, as I have noticed other window-ordering issues, and have even experienced another application fail to accept scroll-wheel input... my guess is that virt-viewer is just more susceptible to whatever the kwin issue is due to my workflow.