search

virtio-win / kvm-guest-drivers-windows

Windows paravirtualized drivers for QEMU\KVM
https://www.linux-kvm.org/page/WindowsGuestDrivers
BSD 3-Clause "New" or "Revised" License
2k stars 385 forks source link

vioinput high DPI mouse rubberbanding #385

Closed tristanpemble closed 4 years ago

tristanpemble commented 5 years ago

I find this issue hard to describe so I made a video to demonstrate.

Essentially, with my mouse set to 1600 DPI, when I move it quickly enough, the mouse will "rubber band" left and right, instead of moving only rightward.

I've tried several configurations, and this only happens when I am using the virtio device with evdev, so I believe it is related to this driver.

tristanpemble commented 5 years ago

changing the libvirt input from "mouse" to "tablet" fixes the mouse movement (but breaks mouse clicks etc being in absolute movement mode)

ybendito commented 5 years ago

Thank you for the report. If I understand correctly the device is able to work with different DPI settings. Several questions:

  1. How exactly you set the mouse resolution? With which resolution setting the mouse works as expected?
  2. Can you please provide 'evtest' output (supported events and properties) for this event device when it is in high DPI mode (will not work correctly) and in other mode(will work correctly)?
  3. What is qemu command line parameters related to the input device? What is the diff between 'libvirt' input 'mouse' and 'tablet'? Thanks
tristanpemble commented 5 years ago

there's been a new development. I can set the mouse to different polling rates. as you lower the polling rate, the problem becomes more easily reproducible, and I can reproduce at the lowest DPI. at the highest polling rate, it becomes more difficult to reproduce, and is only reproducible at higher mouse speed on higher DPIs.

here's a totally subjective table of the speed of mouse movement required for reproducibility. n/r means not reproducible, i.e. I couldn't move my arm fast enough to do it.

125hz 500hz 1000hz
400 dpi high n/r n/r
800 dpi medium high n/r
1600 dpi low medium high
3200 dpi lowest low medium
  1. The mouse has a button on the bottom that changes DPI, with 400/800/1600/3200 options.
  2. I chose to do the two extremes for evtest:
  3. This is how I can reproduce it: 
    -device virtio-mouse-pci,id=input2,bus=pci.0,addr=0xb \
-object input-linux,id=mouse1,evdev=/dev/input/by-id/usb-Kingsis_Peripherals_ZOWIE_Gaming_mouse-event-mouse \

    and I noticed that movement when defining it as a tablet does not reproduce in any case:

    -device virtio-tablet-pci,id=input2,bus=pci.0,addr=0xb \
-object input-linux,id=mouse1,evdev=/dev/input/by-id/usb-Kingsis_Peripherals_ZOWIE_Gaming_mouse-event-mouse \

I also tried adding an entry to local HWDB as described here and saw no change in behavior.

~ λ udevadm info /dev/input/event3 | grep MOUSE_DPI
E: MOUSE_DPI=400@500 800@500 1600@500 3200@500

I know basically nothing about mouse drivers, libinput or evdev. however, given the large differences in event values in the output I am seeing, the sort of "oscillating" behavior of the mouse when it is happening, and the fact that this happens at higher polling and DPIs -- this feels like some kind of overflow error.

ybendito commented 5 years ago

@tristanpemble Can you please provide the output of 'evtest /dev/input/event3'?

tristanpemble commented 5 years ago

yep I provided in above: https://gist.github.com/tristanpemble/ec1c7de47a4dded0575c65f2a33aeb05 https://gist.github.com/tristanpemble/6ba718017abb06acfa96029e7650bbc6

tristanpemble commented 5 years ago

yes, I believe the values are overflowing at this typecast to UCHAR

edit: maybe not exactly there, but I see value represented as UCHAR throughout the file

mbinns commented 5 years ago

Hey I just want to jump in on this thread and comment I ran into the same issue, and @tristanpemble DPI to polling rate table seemed to line up with my results as well

ybendito commented 4 years ago

win8-64-fixed.zip Finally getting to it (better than never) Please confirm the attached driver solves the problem (test mode required to install it, i.e. "bcdedit /set testsigning on" + reboot) The driver is good for x64 win8+

ybendito commented 4 years ago

the fix was released in build 175, please reopen if needed

Boris-Barboris commented 7 months ago

I would like to ask for a re-open. The current fix is simply clamping the input, but the correct solution would not lose the relative input information. The implementation should probably generate multiple HID events (with some sane upper limit) for such an overflow case. Since UCHAR is windows-specific (HID) limitation, I think doing it on hypervisor/libinput level would not be quite right.