Mouse Back & Foward Buttons Don't Work in Virtual Machines
January 20, 2017 4:47 AM Subscribe
Is it a known thing that the back and forward buttons on mice do not work in virtual machines?
I'm using Parallels 12 Pro on an iMac (27-inch Retina late 2015) with Linux guests. Back and forward do not work. The same happens in VirtualBox (and VMware per online complaints).
Googling turns up a considerable number of alleged fixes for VirtualBox and VMware (not Parallels) for both Linux and Windows guests. However, when success is reported, the fix disables the buttons in the host OS. That's not acceptable.
I suspect the VM's aren't enabling the buttons in their mouse emulations. Since it appears to affect a variety of VM products and both Windows and Linux, I'll guess there is a reason.
Does a workaround exist?
I'm using Parallels 12 Pro on an iMac (27-inch Retina late 2015) with Linux guests. Back and forward do not work. The same happens in VirtualBox (and VMware per online complaints).
Googling turns up a considerable number of alleged fixes for VirtualBox and VMware (not Parallels) for both Linux and Windows guests. However, when success is reported, the fix disables the buttons in the host OS. That's not acceptable.
I suspect the VM's aren't enabling the buttons in their mouse emulations. Since it appears to affect a variety of VM products and both Windows and Linux, I'll guess there is a reason.
Does a workaround exist?
Response by poster: @sammyo: X-Mouse is a Windows tool. I'm using Linux guests. Mouse buttons work as expected without additional software on bare metal Linux.
posted by justcorbly at 6:16 AM on January 20, 2017
posted by justcorbly at 6:16 AM on January 20, 2017
This might not be an acceptable solution, but you can connect the mouse directly to the VM, bypassing the host OS entirely. I don't know how to do this in Parallels but VMWare and Virtualbox both have this feature. However, you wouldn't be able to use the mouse in the host OS.
Another possibly-weird solution: Use something like SteerMouse to remap the buttons to an equivalent keyboard shortcut. This might not play nice with Parallels.
posted by neckro23 at 7:38 AM on January 20, 2017 [1 favorite]
Another possibly-weird solution: Use something like SteerMouse to remap the buttons to an equivalent keyboard shortcut. This might not play nice with Parallels.
posted by neckro23 at 7:38 AM on January 20, 2017 [1 favorite]
Your suspicion isn't exactly correct.
Virtual machines present virtual hardware to the guest operating system.
A virtual machine using a virtual hard disk may get to store data on your physical hard disk, but you won't be able to access SMART data or see the full capacity of your hard disk.
An emulated keyboard and mouse are usually implemented as PS/2 compliant devices, because that's the oldest and most portable option.
Virtual hardware usually emulates approximately all the standard functions of the emulated device. Keyboards and mice are a little dicey, because the device you might have in your hand (especially mice) come with fancy add-on drivers and the driver supports extra functions and buttons, sometimes via OS-compliant API's, sometimes through made up driver bull-oney.
There's really no reliable way for a hypervisor to know what buttons might happen to be on your mouse, especially ones that do "extended" functions. As it is, your hypervisor already has to do some tricks to intercept and reconstruct the things you are doing with your mouse. It then has to feed that to the guest driver and encode it to look like a standard mouse. If there's a driver on your platform that is intercepting and "doing things" with additional mouse buttons that can't readily be intercepted, that might not even be a solvable problem.
In VMware Workstation, you can get more than the default two mouse buttons to pass through to a guest, as long as those aren't being captured by some proprietary driver. You would need to add something like
mouse.vusb.enable = "TRUE"
mouse.vusb.useBasicMouse = "FALSE"
to the .vmx file. I think this also switches the mouse to appear to be a USB mouse. Parallels probably has some similar hackery available.
There are a number of upsides to making the mouse look like some sort of standard mouse, including that you can do fun stuff like running a non-touchscreen-OS as a guest on a touchscreen Wintel box and have it work, and that the VM can be moved to a true hypervisor without any hardware dependencies changing.
However, it would suck if you've become used to the convenience of additional mouse shortcuts. I buy these nice Logitech MX Master mice because they're great, but I've never really learned to rely on anything beyond the two buttons and the scroll wheel, because I spend most of my time working on VM's.
The fixes I can imagine include:
1) Make sure there's no proprietary driver intercepting any buttons on the iMac side of things.
2) Find some Parallels configuration directive to pass through a more sophisticated mouse model.
3) Buy a second mouse and pass through the USB directly to the guest, which probably isn't desirable if you are working with multiple guests.
posted by jgreco at 2:38 PM on January 20, 2017 [1 favorite]
Virtual machines present virtual hardware to the guest operating system.
A virtual machine using a virtual hard disk may get to store data on your physical hard disk, but you won't be able to access SMART data or see the full capacity of your hard disk.
An emulated keyboard and mouse are usually implemented as PS/2 compliant devices, because that's the oldest and most portable option.
Virtual hardware usually emulates approximately all the standard functions of the emulated device. Keyboards and mice are a little dicey, because the device you might have in your hand (especially mice) come with fancy add-on drivers and the driver supports extra functions and buttons, sometimes via OS-compliant API's, sometimes through made up driver bull-oney.
There's really no reliable way for a hypervisor to know what buttons might happen to be on your mouse, especially ones that do "extended" functions. As it is, your hypervisor already has to do some tricks to intercept and reconstruct the things you are doing with your mouse. It then has to feed that to the guest driver and encode it to look like a standard mouse. If there's a driver on your platform that is intercepting and "doing things" with additional mouse buttons that can't readily be intercepted, that might not even be a solvable problem.
In VMware Workstation, you can get more than the default two mouse buttons to pass through to a guest, as long as those aren't being captured by some proprietary driver. You would need to add something like
mouse.vusb.enable = "TRUE"
mouse.vusb.useBasicMouse = "FALSE"
to the .vmx file. I think this also switches the mouse to appear to be a USB mouse. Parallels probably has some similar hackery available.
There are a number of upsides to making the mouse look like some sort of standard mouse, including that you can do fun stuff like running a non-touchscreen-OS as a guest on a touchscreen Wintel box and have it work, and that the VM can be moved to a true hypervisor without any hardware dependencies changing.
However, it would suck if you've become used to the convenience of additional mouse shortcuts. I buy these nice Logitech MX Master mice because they're great, but I've never really learned to rely on anything beyond the two buttons and the scroll wheel, because I spend most of my time working on VM's.
The fixes I can imagine include:
1) Make sure there's no proprietary driver intercepting any buttons on the iMac side of things.
2) Find some Parallels configuration directive to pass through a more sophisticated mouse model.
3) Buy a second mouse and pass through the USB directly to the guest, which probably isn't desirable if you are working with multiple guests.
posted by jgreco at 2:38 PM on January 20, 2017 [1 favorite]
Assuming the Linux guests are running X, you can use the xev program to dump out xevents as they are received. This can tell you whether or not the guest is actually getting the button presses. xev run from a terminal pops up a little window, move the mouse to the window and then input events should be mirrored in the terminal, Move to the terminal and Ctrl-C to kill xev.
posted by zengargoyle at 5:50 PM on January 20, 2017
$ xev
...
ButtonPress event, serial 34, synthetic NO, window 0x2e00001,
root 0xee, subw 0x0, time 528271864, (90,81), root:(1601,853),
state 0x0, button 5, same_screen YES
ButtonRelease event, serial 34, synthetic NO, window 0x2e00001,
root 0xee, subw 0x0, time 528271864, (90,81), root:(1601,853),
state 0x1000, button 5, same_screen YES
ButtonPress event, serial 34, synthetic NO, window 0x2e00001,
root 0xee, subw 0x0, time 528272185, (90,81), root:(1601,853),
state 0x0, button 4, same_screen YES
ButtonRelease event, serial 34, synthetic NO, window 0x2e00001,
root 0xee, subw 0x0, time 528272185, (90,81), root:(1601,853),
state 0x800, button 4, same_screen YES
ButtonPress event, serial 34, synthetic NO, window 0x2e00001,
root 0xee, subw 0x0, time 528272192, (90,81), root:(1601,853),
state 0x0, button 7, same_screen YES
...
^C
I've never had a host to guest problem where events don't reach the guest (so YMMV). I have had the guest be stupid and only be configured for the dumbest of 3 button mice and needing some tweaking to actually use the 4-N button events.posted by zengargoyle at 5:50 PM on January 20, 2017
This thread is closed to new comments.
posted by sammyo at 6:10 AM on January 20, 2017