Bug 1214474 - Mouse capture issues when running in vmware
Summary: Mouse capture issues when running in vmware
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker https://fedoraproject...
Keywords: CommonBugs
: 1204393 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-22 19:16 UTC by Jimmy Jones
Modified: 2015-09-01 17:48 UTC (History)
32 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-06-01 17:03:54 UTC


Attachments (Terms of Use)
journalctl -b output (390.55 KB, text/plain)
2015-05-13 20:43 UTC, Jimmy Jones
no flags Details
journalctl -b output using default gnome session (383.48 KB, text/plain)
2015-05-13 21:19 UTC, Everaldo Canuto
no flags Details
journalctl -b output using default wayland session (339.43 KB, text/plain)
2015-05-13 21:22 UTC, Everaldo Canuto
no flags Details

Description Jimmy Jones 2015-04-22 19:16:30 UTC
Description of problem:

When using VMware player 6.0.5 build-2443746 to run Fedora 22 beta, sometimes the host mouse and mouse in the VM get out of sync, so you might move the mouse and it'll loose capture and bring down the VMware bar at the top etc.

Version-Release number of selected component (if applicable):


How reproducible:

Every time

Steps to Reproduce:

1. Install Fedora 22 beta on VMware player

Comment 1 Jimmy Jones 2015-04-22 19:17:23 UTC
Looks similar to #1204393

Comment 2 Everaldo Canuto 2015-04-28 23:12:51 UTC
Yes, very similar and also I can confirm that it also happens on VMware Fusion and VMware Workstation.

Comment 3 Everaldo Canuto 2015-04-28 23:48:12 UTC
Also, same problem even if "3D acceleration" is off.

Comment 4 Martin Chlumsky 2015-04-30 18:16:24 UTC
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.

Comment 5 Everaldo Canuto 2015-05-07 14:03:12 UTC
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.

Comment 6 Rui Matos 2015-05-13 13:39:19 UTC
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.

Comment 7 Jimmy Jones 2015-05-13 20:43:43 UTC
Created attachment 1025184 [details]
journalctl -b output

Comment 8 Everaldo Canuto 2015-05-13 21:19:09 UTC
Created attachment 1025188 [details]
journalctl -b output using default gnome session

Comment 9 Everaldo Canuto 2015-05-13 21:22:31 UTC
Created attachment 1025197 [details]
journalctl -b output using default wayland session

Comment 10 Rui Matos 2015-05-14 09:24:46 UTC
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?

Comment 11 Rui Matos 2015-05-14 09:45:58 UTC
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*).

Comment 12 Rui Matos 2015-05-14 11:39:03 UTC
(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.

Comment 13 Everaldo Canuto 2015-05-14 13:02:49 UTC
xorg-x11-drv-vmmouse already installed by default in Fedora 22 but problem still remains.

I will try move libinput.

Comment 14 Martin Chlumsky 2015-05-14 13:04:57 UTC
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.

Comment 15 Everaldo Canuto 2015-05-14 13:11:17 UTC
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.

Comment 16 Everaldo Canuto 2015-05-14 13:33:31 UTC
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.

Comment 17 Rui Matos 2015-05-14 14:15:08 UTC
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.

Comment 18 Everaldo Canuto 2015-05-14 14:47:59 UTC
Also, looks like it is not only VMware problem, #1204387 report same problem.
Just see it now because I checked all other libinput bugs.

Comment 19 Hans de Goede 2015-05-15 08:51:35 UTC
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

Comment 20 Everaldo Canuto 2015-05-15 09:29:36 UTC
Do we have time for this backport before Fedora 22 final?

Comment 21 Everaldo Canuto 2015-05-15 09:41:09 UTC
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.

Comment 22 Josh Boyer 2015-05-15 11:37:48 UTC
(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.

Comment 23 Everaldo Canuto 2015-05-15 11:47:31 UTC
(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?

Comment 24 Rui Matos 2015-05-15 13:57:46 UTC
*** Bug 1204393 has been marked as a duplicate of this bug. ***

Comment 25 Adam Williamson 2015-05-15 21:21:00 UTC
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).

Comment 26 Everaldo Canuto 2015-05-15 21:32:31 UTC
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.

Comment 27 Everaldo Canuto 2015-05-15 21:43:53 UTC
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.

Comment 28 Adam Williamson 2015-05-15 22:06:29 UTC
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.

Comment 29 Everaldo Canuto 2015-05-15 22:13:48 UTC
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.

Comment 30 Jimmy Jones 2015-05-16 13:27:21 UTC
Same here, if I remove 90-libinput.conf my touchpad stops working entirely

Comment 31 Everaldo Canuto 2015-05-16 13:30:05 UTC
(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?

Comment 32 Adam Williamson 2015-05-16 15:18:14 UTC
Is xorg-x11-drv-synaptics installed? If not, does installing it make things work?

Comment 33 Rui Matos 2015-05-16 16:47:09 UTC
(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*

Comment 34 Jack Evans 2015-05-16 18:24:56 UTC
xorg-x11-drv-synaptics is installed and the host is windows so file definitely removed on guest!

Comment 35 Jimmy Jones 2015-05-16 19:29:36 UTC
My host is Linux, but checked and I removed 90-libinput.conf from guest.

Comment 36 Everaldo Canuto 2015-05-17 02:03:31 UTC
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.

Comment 37 Hans de Goede 2015-05-17 09:38:40 UTC
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

Comment 38 Jimmy Jones 2015-05-17 12:56:27 UTC
Can confirm the fix works for me. Look forward to the proper fix post GA.

Comment 39 Everaldo Canuto 2015-05-17 14:47:27 UTC
I can confirm this workaround also works for me.

Comment 40 Jack Evans 2015-05-17 15:53:28 UTC
Works for me too

Comment 41 Peter Hutterer 2015-05-18 00:48:06 UTC
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.

Comment 42 Everaldo Canuto 2015-05-18 01:04:51 UTC
(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?

Comment 43 Peter Hutterer 2015-05-18 02:15:39 UTC
(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/

Comment 44 Jaroslav Reznik 2015-05-18 12:23:37 UTC
Based on comment #37, -1 blocker/-1 FE.

Comment 45 Jimmy Jones 2015-05-18 13:43:17 UTC
Will the workaround be included in the final release notes?

Comment 46 Stephen Gallagher 2015-05-18 15:38:59 UTC
-1 blocker, -1 FE

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

Comment 47 Petr Schindler 2015-05-18 17:06:53 UTC
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

Comment 48 Jim Adkins 2015-05-18 18:28:20 UTC
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.

Comment 49 sultanqasim 2015-05-18 21:39:24 UTC
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.

Comment 50 Peter Hutterer 2015-05-19 01:06:28 UTC
(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).

Comment 51 Hans de Goede 2015-05-19 07:48:27 UTC
(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.

Comment 52 Thomas Hellström 2015-05-19 12:42:32 UTC
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

Comment 53 sultanqasim 2015-05-19 12:59:20 UTC
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).

Comment 54 Sergey V. Udaltsov 2015-05-26 22:26:23 UTC
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.

Comment 55 Kamil Páral 2015-05-27 08:03:42 UTC
Sergey, have you tried the suggestion in comment 4? Does it work you?

Comment 56 Sergey V. Udaltsov 2015-05-27 10:22:00 UTC
Kamil, yes I tried this now. No difference.

Comment 57 Josh Boyer 2015-05-27 12:32:15 UTC
I'm working on the backport for this today.

Comment 58 Josh Boyer 2015-05-27 14:19:39 UTC
Patch is in F22 git.  It will be in the next f22 kernel build.

Comment 59 Sergey V. Udaltsov 2015-05-27 14:46:22 UTC
When would you expect it to hit the official update channel? Thank you for the quick fix!

Comment 60 fedher 2015-05-27 19:06:00 UTC
waiting for update too...

Comment 61 Thomas Hellström 2015-05-28 07:39:15 UTC
(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

Comment 62 Josh Boyer 2015-05-28 11:24:35 UTC
Oops, I missed that.  I'll add that today.

Comment 63 Josh Boyer 2015-05-28 11:38:03 UTC
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 64 Matt Domsch 2015-05-28 15:44:43 UTC
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!

Comment 65 Fedora Update System 2015-05-28 20:40:50 UTC
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

Comment 66 Fedora Update System 2015-05-30 15:57:06 UTC
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).

Comment 67 Jimmy Jones 2015-05-31 10:10:51 UTC
Just tried in a new install and works as before - thanks!

Comment 68 Jimmy Jones 2015-05-31 10:11:33 UTC
Someone might want to update the "Fedora Update System" message to say dnf rather than yum though!

Comment 69 Jimmy Jones 2015-05-31 10:23:17 UTC
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)

Comment 70 Loïc Yhuel 2015-06-01 00:35:34 UTC
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

Comment 71 Thomas Hellström 2015-06-01 09:47:13 UTC
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

Comment 72 Fedora Update System 2015-06-01 17:03:54 UTC
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.

Comment 73 Loïc Yhuel 2015-06-01 21:52:07 UTC
(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

Comment 74 Thomas Hellström 2015-06-02 22:06:00 UTC
(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

Comment 75 Ryan M 2015-06-17 22:36:50 UTC
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?

Comment 76 j.c 2015-06-21 09:26:19 UTC
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.

Comment 77 j.c 2015-06-21 10:56:44 UTC
(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

Comment 78 Sebastian Bergmann 2015-06-21 12:01:19 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1227193 is much more frustrating.

Comment 79 Brian de Alwis 2015-09-01 17:48:43 UTC
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


Note You need to log in before you can comment on or make changes to this bug.