Description of problem: After upgrading to F28, the first regression I noticed was that when using the mouse wheel inside a virtual machine, there is a sort of "buffer" in either direction that must be filled before it begins registering a scroll event. The buffer is 3 turns. For example, if I want to scroll down, it takes 3 downward turns before 1 turn is registered inside the virtual machine. From that point, any downward turn is registered. But if I then want to scroll up, it takes 3 upward turns before the turns begin to register. Scrolling up then works fine, but I must again scroll 3 times if I want to scroll downward. I've tried using both Wayland and X on GNOME. A myriad of video settings (QXL/Spice/etc) in virt-manager. Upgrading the VMs to F28. Different mouses. No luck. This critically destroys my workflow and I consider it a severe UI regression. Scrolling is messed up, some simple UI actions have become tedious. Version-Release number of selected component (if applicable): 1.5.1 How reproducible: Seems to be 100% reproducible. Steps to Reproduce: 1. Upgrade to Fedora 28 2. Try to scroll with mouse wheel while using a virtual machine Actual results: Mouse wheel behavior seems to have a "dead zone" of 3 turns Expected results: Mouse wheel behavior mimics behavior Additional info: I'm not sure if virt-manager is to blame, but I'm just not sure what a better component would be. Feel free to change it.
I reproduced, basically exactly what you describe, scroll doesn't move for me until the third click. But for me it's specific to spice graphics. I bisected spice-gtk and it seems to be this commit which entered Fedora with 0.35 version commit 2212f05145c5f1d5734f0cb7d3945dc58c1d5c8c Author: Marc-André Lureau <marcandre.lureau> Date: Thu Jun 7 19:32:09 2018 +0200 widget: handle smooth-scroll events
Very interesting. I had a suspicion it was related to Spice and came upon that very commit after searching release notes, but for some reason I thought that after switching to VNC the problem still presented itself. Testing again, it works fine now. This seems like it will be an easy fix then, because if I remember correctly, that commit specifically deals with detecting smooth scroll events with touchpads on Wayland. It's likely a dev was just lazy and didn't correctly differentiate between events originating from a regular mouse and touchpad.
(In reply to User from comment #2) > It's likely a dev was just lazy and didn't > correctly differentiate between events originating from a regular mouse and > touchpad. For what it's worth, this kind of comments is not particularly welcome..
I apologize if that was inappropriate. I was just joking about the lazy bit, we all make mistakes when developing software and I appreciate all of the hard work that has gone into Spice.
Sent a possible fix [0] but not sure if that's great solution still. Feel free to give feedback based on scratch-build [1] below [0] https://lists.freedesktop.org/archives/spice-devel/2018-September/045574.html [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=29669518
spice-gtk-0.35-3.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f2d2ea7fd9
spice-gtk-0.35-3.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-f2d2ea7fd9
spice-gtk-0.35-3.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.