Vmware player mac os x jittery mouse driver#

The fix for it will be to add a special hardware database entry for a *single model of mouse*: unless you have that precise mouse model, the bug isn't relevant to you at all. There will be bugs with particular bits of hardware that do odd things #1204387 was one of those. Yes, libinput is a new thing which changes behaviour part of the point of Fedora is to be one of the places where such changes land and get shaken out. You can't declare 'libinput doesn't do exactly the same thing as evdev' to be a Single Bug that must Be Fixed before F22 is released. #1204387 is nothing at all like this bug: it was mis-detection of the DPI of a particular mouse model. I don't think you're characterizing things correctly. So I'm changing the component for this bug to kernel. IMHO 2 clearly is the correct solution, so IMHO the solution for this would be to backport the kernel support for this to the F-22 kernel:

Vmware player mac os x jittery mouse driver#

is progressing upstream and an in kernel driver for the vmmouse has been merged recently. Which also has the advantage that it does not break when the xserver runs as a regular user (and thus cannot do direct hardware access), something which we are already doing when using gdm or startx under F-22:ДЄs said work on 2. Upstream is heading in the direction of 2. So there are 2 possible solutions for this:ДЎ) Add an extra check to the nf file to make it not override the vmmouse driverДў) Bring vmouse in line with how we deal with pretty much any other input device and have an in kernel driver for it rather then relying on an xserver userspace driver which does direct bit-banging to the hardware