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).
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.
- 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,
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...
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.