Bug 1214474

Looks similar to #1204393

Yes, very similar and also I can confirm that it also happens on VMware Fusion and VMware Workstation.

Also, same problem even if "3D acceleration" is off.

I have the same problem with Fedora 22 Beta on VMWare Player 7.1.0 (Windows 8.1).

I just found a workaround:

Edit C:\Users\<username>\AppData\Roaming\VMware\preferences.ini and add the following 3 lines:

pref.motionUngrab = "FALSE"
pref.grabOnMouseClick = "TRUE"
pref.motionGrab = "FALSE"

The mouse will no longer be grabbed as you pass over the VM. You will have to click on it.
To ungrab, you'll have to press ctrl-alt.

I found this less frustrating.

On #1204393 Torsten just commented:

> I went to fedora-devel. People suggested to change the component to gnome-shell and
> to inform also vmware about it. Have only done the former so far.

Maybe is a good idea to change component to gnome-shell to get people looking at this bug before Fedora 22 final.

Can one of you attach a 'journalctl -b' output (after having logged in to your user account in the guest)? There are many things that might be going wrong and having a full log will cut on the NEEDINFO roundtrips here.

Created attachment 1025184 [details]
journalctl -b output

Created attachment 1025188 [details]
journalctl -b output using default gnome session

Created attachment 1025197 [details]
journalctl -b output using default wayland session

So, to be clear, the problem is that the mouse grab that the vmware window holds to keep events going exclusively to it is released when it shouldn't? Does this happen with other desktop environments in the F22 guest?

If you do:

sudo mv /usr/share/X11/xorg.conf.d/{90,49}-libinput.conf

and log in to the gnome session again does it work then?

I suspect the problem is that the new libinput driver is being loaded instead of vmmouse due to its configuration file overriding vmmouse's since they seem to match on the same thing (MatchIsPointer) and libinput's coming later (90* > 50*).

(In reply to Rui Matos from comment #11)
> I suspect the problem is that the new libinput driver is being loaded
> instead of vmmouse due to its configuration file overriding vmmouse's since
> they seem to match on the same thing (MatchIsPointer) and libinput's coming
> later (90* > 50*).

actually I got this backwards. The way X conf files work is that the first wins so vmmouse should end up being used for this device.

So, do you have xorg-x11-drv-vmmouse installed in the guest? If not, try installing it.

xorg-x11-drv-vmmouse already installed by default in Fedora 22 but problem still remains.

I will try move libinput.

Is it possible that the RPM needs to be rebuilt for Fedora 22?

xorg-x11-drv-vmmouse-13.0.0-13.fc21.x86_64


All other xorg-x11-drv-* RPMs are fc22.

Hey, I just moved 90-libinput.conf out of /usr/share/X11/xorg.conf.d/ and now everything works fine. Also, the mouse that was very slow now works properly like in F21.

So, the problem is with 90-libinput.conf. How we can get it fixed by default in Fedora 22? I know that delete move this file is not hard for technical users but it much better to have it working by default like on previous versions.

Looking at Fedora 21 I can see that we don't have 90-libinput.conf.

So, any chance to have 90-libinput.conf not installed by default or do we need to fix libinput.

I'll move this to the xorg-x11-drv-libinput package for now since that's what installs the configuration file that seems to be overriding the vmmouse configuration.

Also, looks like it is not only VMware problem, #1204387 report same problem.
Just see it now because I checked all other libinput bugs.

Hi,

Thanks for the bugreport.

So there are 2 possible solutions for this:

1) Add an extra check to the 90-libinput.conf file to make it not override the vmmouse driver
2) 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

Upstream is heading in the direction of 2. 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:
http://hansdegoede.livejournal.com/15767.html

As said work on 2. is progressing upstream and an in kernel driver for the vmmouse has been merged recently. 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:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=8b8be51b4fd365ac5983e117be9d28f427a07b68

So I'm changing the component for this bug to kernel.

Regards,

Hans

Do we have time for this backport before Fedora 22 final?

Ah, one more note. Just tested to move 90-libinput.conf on a VMware Fusion without mouse and touchpad don't works.

So, this solution maybe don't works when using touchpad.

(In reply to Everaldo Canuto from comment #20)
> Do we have time for this backport before Fedora 22 final?

No.  This would have to be a Blocker or freeze exception.  I'm doubtful it would qualify.

(In reply to Josh Boyer from comment #22)
> (In reply to Everaldo Canuto from comment #20)
> > Do we have time for this backport before Fedora 22 final?
> 
> No.  This would have to be a Blocker or freeze exception.  I'm doubtful it
> would qualify.

The problem is that we have more problems related to mouse. IMHO, even if we need to delay Fedora 22, we must do it because I am having a lot of troubles with mouse on F22 and looks at the list of libinput bugs, I am not alone.

How we can work to convince about blocker exception?

*** Bug 1204393 has been marked as a duplicate of this bug. ***

This does not look serious enough to constitute a blocker. VMware is not even one of the virtualization platforms we list in the release criteria (the main supported virt stack is the KVM/libvirt stack, we also support Xen), and even if it were, this seems like it has a fairly trivial workaround (just remove xorg-x11-drv-libinput).

-1 blocker. Even freeze exception seems a little questionable, as it seems to involve a fairly large kernel change (though in an ideal world it'd be desirable to do this pre-release rather than post-release, so it'd be fixed on lives).

As I mentioned before, remove xorg-x11-drv-libinput don't works for touchpads (very common on laptops). Also, we have bugs like #1200717 and #1204387 that looks to be same issue since I experienced the problem on non-virtualized environments.

For me looks like we have serious issues with libinput that could be fixed before F22 final. Also, without this not only me but also a lot of other people will be unable to run Fedora on next 6~7 months.

You could arg that it #1204387 is the blocker bug, in this case, will be better to mark this as duplicate of #1204387 and mark #1204387 as release blocker.

Also I will check Parallels, VirtualBox, Xen, KVM and all other computer available for me before monday meeting. I am convinced that this bug affects much more environments than we think.

I don't think you're characterizing things correctly. #1204387 is nothing at all like this bug: it was mis-detection of the DPI of a particular mouse model. 

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. That's just not how it goes. 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. There will be bugs with particular bits of hardware that do odd things; #1204387 was one of those. 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.

"As I mentioned before, remove xorg-x11-drv-libinput don't works for touchpads"

Frankly, I'm not convinced that's the same problem. Whether the host has a mouse or touchpad shouldn't affect the actual *guest* bug that's being addressed here.

Ok, I just tested here, using mouse and removing libinput workaround works. With touchpad, when remove libinput touchpad don't works at all.

Anyway, maybe not too much people uses VMware Fusion and Workstation, here, at office 6 people use but maybe it is just us. For us, it looks like a blocker because we can't use F22.

We are probably going to stick with F21 or try Ubuntu GNOME as we understand that VMware tools is not supported.

Same here, if I remove 90-libinput.conf my touchpad stops working entirely

(In reply to jimmyjones2 from comment #30)
> Same here, if I remove 90-libinput.conf my touchpad stops working entirely

Don't you think this is a blocker release bug? Or I think it is blocker just because it affects me?

Is xorg-x11-drv-synaptics installed? If not, does installing it make things work?

(In reply to jimmyjones2 from comment #30)
> Same here, if I remove 90-libinput.conf my touchpad stops working entirely

Are you doing this in the host? 

I suggested that work around to be done in the *guest*

xorg-x11-drv-synaptics is installed and the host is windows so file definitely removed on guest!

My host is Linux, but checked and I removed 90-libinput.conf from guest.

xorg-x11-drv-synaptics also installed here and problem still remain. The host is OSX so I am sure 90-libinput.conf is removed from guest.

Hi All,

To work around this you likely need to both remove 90-libinput.conf and create a:

/etc/X11/Xwrapper.config

File with following in there:

needs_root_rights = yes

As said the vmmouse driver needs root rights, and we no longer run the Xserver as root by default because of security issues with running Xorg as root.

Sorry about this, but the vmmouse driver doing direct io from userspace has been an ugly hack for much too long, and was bound to break at some point in time. I only which we had caught the breakage earlier so that we could have fixed this for F-22 GA. I'm pretty confident that we can up with a fix post F-22 GA soon, but we're not going to be able to do this for F-22 final.

Given that things do work in F-22 as is, I really cannot see this as a blocker. Also note that you should be able to tell vmware to emulate a usb mouse or tablet instead of the ps2 vmmouse and that should work too.

Regards,

Hans

Can confirm the fix works for me. Look forward to the proper fix post GA.

I can confirm this workaround also works for me.

Works for me too

The following should be sufficient and remove the need to drop libinput:

sudo ln -s /usr/share/X11/xorg.conf.d/50-vmmouse.conf /etc/X11/xorg.conf.d/99-vmmouse.conf

The problem we have with the xorg.conf.d is that we can only add or override options and drivers, and we can only add positive matches. So what happens is:
* the evdev match applies the evdev driver
* the vmmouse snippet matches, overwrites with vmmouse
* the libinput snippet matches on all pointers, overwrites with libinput

Only one driver is possible, so the last one wins, and libinput is sorted last. But you can use the same snippet twice with different sorting order, so if 99-vmmouse.conf sorts after the libinput snippet it will overwrite the other bits again.

There isn't an easier solution to this atm, the xorg.conf matching can't do negative matches, so we can't say "don't match on vmmouse" or "match on anything but vmmouse".

This workaround still requires the Xwrapper.config changes outlined by Hans in Comment 37.

(In reply to Peter Hutterer from comment #41)
> The following should be sufficient and remove the need to drop libinput:
> 
> sudo ln -s /usr/share/X11/xorg.conf.d/50-vmmouse.conf
> /etc/X11/xorg.conf.d/99-vmmouse.conf
> 
> The problem we have with the xorg.conf.d is that we can only add or override
> options and drivers, and we can only add positive matches. So what happens
> is:
> * the evdev match applies the evdev driver
> * the vmmouse snippet matches, overwrites with vmmouse
> * the libinput snippet matches on all pointers, overwrites with libinput
> 
> Only one driver is possible, so the last one wins, and libinput is sorted
> last. But you can use the same snippet twice with different sorting order,
> so if 99-vmmouse.conf sorts after the libinput snippet it will overwrite the
> other bits again.
> 
> There isn't an easier solution to this atm, the xorg.conf matching can't do
> negative matches, so we can't say "don't match on vmmouse" or "match on
> anything but vmmouse".
> 
> This workaround still requires the Xwrapper.config changes outlined by Hans
> in Comment 37.

Hi Peter, why have you used /etc/X11/xorg.conf.d/99-vmmouse.conf instead of /usr/share/X11/xorg.conf.d/99-vmmouse.conf ? It works only on etc or I can use both paths?

(In reply to Everaldo Canuto from comment #42)
> Hi Peter, why have you used /etc/X11/xorg.conf.d/99-vmmouse.conf instead of
> /usr/share/X11/xorg.conf.d/99-vmmouse.conf ? It works only on etc or I can
> use both paths?

/usr/share is for distribution-provided configuration and can get overwritten during updates. /etc is for local configurations. You can use either, but localised configuration should always go into /etc/

Based on comment #37, -1 blocker/-1 FE.

Will the workaround be included in the final release notes?

-1 blocker, -1 FE

We can put this in Common Bugs so people know of the workaround.

Discussed at today's blocker review meeting [1]. 

This bug was rejected as blocker: VMWare isn't a supported virtualization platform for Fedora. Rejected as a blocker. Please document the workaround in CommonBugs.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-05-18

I attempted the following workaround:

sudo ln -s /usr/share/X11/xorg.conf.d/50-vmmouse.conf /etc/X11/xorg.conf.d/99-vmmouse.conf


... and now, after restarting the VM, the mouse/pointer is completely unresponsive.


Running VMware 6.0.6 build-2700073 on Windows 7 x64.

Peter's workaround worked fine for me with VMware Fusion 7.1.1 on Mac OS X 10.10.3 as the host and Fedora 22 TC4 as the guest:

sudo ln -s /usr/share/X11/xorg.conf.d/50-vmmouse.conf /etc/X11/xorg.conf.d/99-vmmouse.conf

The mouse continues to work correctly for me, even after reboots and such.

While I accept that this was rejected as a blocker because VMware is not an officially support virtualization tool, this bug does make for a bad out-of-box user experience for someone trying out fedora with the livecd. VMware is the most popular and usable cross platform virtualization tool.

I hope that if nothing else, a fix can be put in updates after GA. I understand that fixing this has been rejected as a blocker, but I think users would be happier if the mouse worked correctly out of the box on the most popular virtualization platform.

(In reply to Jim Adkins from comment #48)
> I attempted the following workaround:
> 
> sudo ln -s /usr/share/X11/xorg.conf.d/50-vmmouse.conf
> /etc/X11/xorg.conf.d/99-vmmouse.conf
> 
> ... and now, after restarting the VM, the mouse/pointer is completely
> unresponsive.

did you also put the Xwrapper change in place?


For the archive, Hans has been working with the Fedora kernel guys so this should be properly resolved in rawhide very soon and F22 GA (hopefully).

(In reply to Peter Hutterer from comment #50)
> For the archive, Hans has been working with the Fedora kernel guys so this
> should be properly resolved in rawhide very soon and F22 GA (hopefully).

Correction, we are working on getting a kernel fix in place for F-22, but this is going to be done in the form of a post GA kernel update (which may well be available at the day of GA), which should not be a big deal since things do work.

The only thing you loose from not having the vmmouse driver is the mouse being able to seemlessly leave / enter the window. Instead it should get grabbed on the first click, and then only show the guest windows cursor. At leats that is how all other virtual machines work when there is no absolute mouse driver like vmmouse. If vmplayer behaves differently then that really is a vmplayer bug.

Hi!

Just a couple of comments after reading this bug

1) The vmmouse kernel driver is probably the way to go, but Don't use it with an old user-space driver. The drivers will compete and steal events from oneanother. Better to remove the user-space driver completely. The Kconfig help text is also incorrect w r t the xf86-input-vmmouse version, it should say 13.1.0 instead of 13.0.1. 13.0.99 will become 13.1.0 as soon as testing is finished and we have currently no bugs reported against 13.0.99. Backporting the vmmouse kernel driver should be trivial.

2) The purpose of the vmmouse driver is primarily to reduce cursor lag, particularly on, but not restricted to, remote VMs. The grab / ungrab functionality comes with an extra bonus.

3) IIRC QEMU / KVM also supports the vmmouse. We haven't tested the kernel driver in that configuration so that should probably be done.

4) A small patch is needed for the kernel's joydev.c joystick driver to stop it detecting the vmmouse as a joystick. It should hopefully be in 4.1 when it's released.

Thanks,
Thomas

Without he vmmouse driver, the mouse is barely usable on my setup (Mac with VMware fusion). When the vm is fullscreen, the mouse is out of sync with the pointer most of the time, even after clicking. Autohidden menus keep popping up all the time when I move the mouse to the edge of the screen, and clicking does not click where the mouse pointer is, since it shows the Mac pointer 70% of the time, and the Mac pointer is out of sync with the VM pointer. It took a lfair bit of frustration to be just to be able to get a terminal open with a mouse so that I could perform the workaround (I suppose I could have used the keyboard to open the terminal though).

Same here, in VMWare Fusion.

If I put needs_root_rights=true to Xwrapper.config - I cannot login any more (have to reboot to single user to change it back). Please kindly advise!

Is there any ETA for vmmouse fix? It is quite difficult to use fedora without a mouse at all.

In Xorg.0.log I can see it is using vmmouse driver, no need to play with the numbering of .conf files.

Sergey, have you tried the suggestion in comment 4? Does it work you?

Kamil, yes I tried this now. No difference.

I'm working on the backport for this today.

Patch is in F22 git.  It will be in the next f22 kernel build.

When would you expect it to hit the official update channel? Thank you for the quick fix!

waiting for update too...

(In reply to Josh Boyer from comment #58)
> Patch is in F22 git.  It will be in the next f22 kernel build.

Hi!

Please don't forget to add joydev commit 15397f of linus' tree:

"Input: joydev - don't classify the vmmouse as a joystick"

And also remove / update the xf86-input-vmmouse driver.

Thanks,

Thomas

Oops, I missed that.  I'll add that today.

I've added commit 15397f now.

The kernel package has a Conflicts on xorg-x11-drv-vmmouse (Fedora's naming of xf86-input-vmmouse) less than the version necessary already.

Comment 37 + Comment 41 works for me now; before the mouse worked at the login  screen, but not at all thereafter.  Now it's working as expected. thanks!

kernel-4.0.4-303.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/kernel-4.0.4-303.fc22

Package kernel-4.0.4-303.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-4.0.4-303.fc22'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-9227/kernel-4.0.4-303.fc22
then log in and leave karma (feedback).

Just tried in a new install and works as before - thanks!

Someone might want to update the "Fedora Update System" message to say dnf rather than yum though!

For VMware users out there, you might also be interesting in bug 1222216 - not being able to get full resolution with Wayland (eg. gdm login screen, or when running a full Wayland session instead of X)

Going from xorg-x11-drv-vmmouse to the vmmouse kernel driver causes two different issues for me, depending on which xorg driver I install :
 - with xorg-x11-drv-evdev, in at least in kate and konsole, when I move the mouse and the scroll wheel at the same time, it scrolls up and down
 - with xorg-x11-drv-libinput, the mouse wheel always scrolls by one line regardless of mouse kcm settings

Hi!

(In reply to Loïc Yhuel from comment #70)
> Going from xorg-x11-drv-vmmouse to the vmmouse kernel driver causes two
> different issues for me, depending on which xorg driver I install :
>  - with xorg-x11-drv-evdev, in at least in kate and konsole, when I move the
> mouse and the scroll wheel at the same time, it scrolls up and down

I'm not fully sure what you are expecting here? I tested the vmmouse kernel driver moving the mouse in a gnome-terminal while moving the scroll wheel at the same time, and it didn't scroll, or scrolled erratically. However in emacs this seems to work fine. Also when I tested the vmware USB mouse I saw identical behaviour. However, with xf86-input-vmmouse it scrolls nicely up and down even in gnome-terminal, so there is some discrepancy. Since the USB mouse is behaving identically, I don't think the problem is in the vmmouse driver, though.


>  - with xorg-x11-drv-libinput, the mouse wheel always scrolls by one line
> regardless of mouse kcm settings

The weel motion is currently always presented on the relative vmouse device (there is one absolute and one relative). Could it be that you are trying to alter settings for the incorrect device? (Never used kcm, so bare with me if this doesn't make sense :)).

Thanks,
Thomas

kernel-4.0.4-303.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

(In reply to Thomas Hellström from comment #71)
> Hi!
> 
> (In reply to Loïc Yhuel from comment #70)
> > Going from xorg-x11-drv-vmmouse to the vmmouse kernel driver causes two
> > different issues for me, depending on which xorg driver I install :
> >  - with xorg-x11-drv-evdev, in at least in kate and konsole, when I move the
> > mouse and the scroll wheel at the same time, it scrolls up and down
> 
> I'm not fully sure what you are expecting here? I tested the vmmouse kernel
> driver moving the mouse in a gnome-terminal while moving the scroll wheel at
> the same time, and it didn't scroll, or scrolled erratically. However in
> emacs this seems to work fine. Also when I tested the vmware USB mouse I saw
> identical behaviour. However, with xf86-input-vmmouse it scrolls nicely up
> and down even in gnome-terminal, so there is some discrepancy. Since the USB
> mouse is behaving identically, I don't think the problem is in the vmmouse
> driver, though.
It could be a bug in xorg-x11-drv-evdev, but it doesn't happen with a real mouse, so perhaps it's linked to the separate relative/absolute mouses. For the applications, perhaps it only happens when xinput2 is used (Qt5 for example).
> 
> 
> >  - with xorg-x11-drv-libinput, the mouse wheel always scrolls by one line
> > regardless of mouse kcm settings
> 
> The weel motion is currently always presented on the relative vmouse device
> (there is one absolute and one relative). Could it be that you are trying to
> alter settings for the incorrect device? (Never used kcm, so bare with me if
> this doesn't make sense :)).
This is in fact a KDE-only settings, which is applied to Qt applications (QApplication::setWheelScrollLines). It doesn't work in kate with libinput, a bug is already reported (https://bugzilla.redhat.com/show_bug.cgi?id=1220101), I will post my analysis there.
> 
> Thanks,
> Thomas

(In reply to Loïc Yhuel from comment #73)
> (In reply to Thomas Hellström from comment #71)
> > Hi!
> > 
> > (In reply to Loïc Yhuel from comment #70)
> > > Going from xorg-x11-drv-vmmouse to the vmmouse kernel driver causes two
> > > different issues for me, depending on which xorg driver I install :
> > >  - with xorg-x11-drv-evdev, in at least in kate and konsole, when I move the
> > > mouse and the scroll wheel at the same time, it scrolls up and down
> > 
> > I'm not fully sure what you are expecting here? I tested the vmmouse kernel
> > driver moving the mouse in a gnome-terminal while moving the scroll wheel at
> > the same time, and it didn't scroll, or scrolled erratically. However in
> > emacs this seems to work fine. Also when I tested the vmware USB mouse I saw
> > identical behaviour. However, with xf86-input-vmmouse it scrolls nicely up
> > and down even in gnome-terminal, so there is some discrepancy. Since the USB
> > mouse is behaving identically, I don't think the problem is in the vmmouse
> > driver, though.
> It could be a bug in xorg-x11-drv-evdev, but it doesn't happen with a real
> mouse, so perhaps it's linked to the separate relative/absolute mouses. For
> the applications, perhaps it only happens when xinput2 is used (Qt5 for
> example).

FWIW, vmmouse in gnome-terminal in gnome/Wayland works as expected (except the pointer hotspot is slightly off), so this points to something wrong in the Xorg input drivers...

/Thomas

I'm seeing a problem that I think is the same as the one reported in this bug.  I'm running a fully updated F22 guest on a Windows machine in VMware Workstation.  When in windowed mode or single-screen fullscreen mode, the VM mouse behaves as expected.  When I switch to a dual-monitor fullscreen mode for the VM, the mouse no longer clicks where the cursor is.  It is about 1/4 of the screen to the right of the cursor, but correctly aligned vertically.  Does this sound related to you, and are there any workarounds you can think of?

I am not able to install fedora 22 under vmware player, wmvare workstation on my two computers. Mouse cursor is showing but mouse is working not.

(In reply to j.c from comment #76)
> I am not able to install fedora 22 under vmware player, wmvare workstation
> on my two computers. Mouse cursor is showing but mouse is working not.

workaround working in vmware player:
https://github.com/rharmonson/richtech/wiki/Fedora-22,-VMware-Workstation-11,-&-Erratic-Mouse

https://bugzilla.redhat.com/show_bug.cgi?id=1227193 is much more frustrating.

FWIW, I found life was better in VMWare Fusion (6.x) by using Cmd-G to grab the cursor.

http://pubs.vmware.com/fusion-5/index.jsp?topic=%2Fcom.vmware.fusion.help.doc%2FGUID-8905F215-ED84-4C5D-80A9-C372670321FC.html