Mouse X,Y Coordinates

[jeffpalnosewort]

Hi,

I have a application which I am running on VMware Workstation Pro with Windows 10 64bit OS. It captures mouse coordinates and sends it to a piece of hardware to move the mouse on it using the X,Y coordinates and the delta of the movement. On a bare metal machine I get normal X,Y coordinates but in the VM I get extremely high values that he opposite hardware doesn't understand. Any idea what the high values represent? or how to receive normal values in the VM?

[Mits2020]

This depends very much on the method by which your program gets the mouse coordinates. I would start by running several (not just one) free programs like the ones listed in https://www.ilovefreesoftware.com/18/featured/show-mouse-coordinates-desktop-screen.html to ensure that the VMware graphics driver behaves normally.

We also need to know how the PC and the VM send the information to that "piece of hardware". They communicate via serial/parallel port cable, by USB cable, by ethernet, by wireless or what exactly?

[jeffpalnosewort]

The hardware is a radar processor. the coordinates are sent by Ethernet. The coordinates from the VM are too high compared to a bare metal machine.

[dariusd]

I would guess that the cause of the problem is that the program inside the guest is assuming its input device is a regular mouse, but VMware Workstation does not emulate a regular mouse – and for very good reasons, as you will read below.  Instead, we emulate a graphics tablet (or really just a generic absolute pointer device) which sends coordinates in some quite large range.  The virtual absolute pointing device typically reports coordinates in a rectangle that is something like (0,0)-(32767,32767), and the guest OS will map that onto its screen.

You can turn off the absolute mouse pointer support – and give the virtual machine something that looks more like a regular mouse – by editing your VM's configuration file (the .vmx file) to include the following line:

   mouse.vusb.absDisabled = "TRUE"

But note the following:

1. This will disable "auto-grab", which is the feature that normally allows you to simply move the mouse pointer into the VM's window to interact with the VM and move it back out again to the host when you want.  You have to click on the VM to start interacting with it, and you have to hit the Ctrl+Alt keys on the keyboard to return control from the guest to the host.  (An absolute pointing device allows us to detect when the pointer is about to leave the guest window, allowing us to automatically return to the host, but a relative pointer can not do that.)

2. The guest mouse pointer will not reposition itself to correspond with the host mouse pointer when you click on the guest window... The guest mouse pointer will stay wherever it was when you left the guest last time.  (An absolute pointing device allows us to "warp" the guest pointer to the correct location automatically.)

3. The guest mouse pointer movement is likely to be "sluggish".  You might be able to partially correct this by tweaking the guest pointer acceleration settings.  (An absolute pointing device bypasses guest pointer acceleration settings by its very nature, while a relative pointer will go through guest pointer acceleration and host pointer acceleration, which is why it feels sluggish.)

The problem can also potentially be addressed by modifying the software inside the guest so that it does not make unsafe assumptions about its input device... but the above configuration should make our pointing device behave a bit more like a physical machine's.

Hope this helps!

--

Darius

[Mits2020]

Thanks dariusd, very interesting information about vusb... would this still apply if we used a second separate wireless or bluetooth mouse after passing its usb receiver dongle into the guest?

[dariusd]

A passed-through USB HID would work in the VM as a separate pointing device, just like it would on a physical machine with two pointing devices (e.g. a mouse and a graphics tablet).

In the presence of two relative pointing devices (e.g. one passed-through USB mouse and an emulated relative pointing device), each can be used independently, and the results will generally be additive.

In the presence of one absolute pointing device and one relative pointing device (e.g. one passed-through USB mouse and an emulated absolute pointing device), the absolute pointing device will set the pointer's absolute position each time it moves, but any relative pointing device input will allow the cursor to move from that point until the next absolute input overrides it again.

A passed-through USB pointing HID will not be able to grab/ungrab from the host, regardless of whether it is an absolute pointer (graphics tablet) or relative pointer (mouse); The grab/ungrab behavior is unique to the VMware emulated absolute pointer, and any passed-through USB pointing HID will be constrained to the guest screen only.  A passed-through USB pointing HID will only be subjected to the guest's pointer acceleration, not the host's.

--

Darius

[Mits2020]

Thanks for the very comprehensive answer, Darius. But disregarding the inconvenience of grabbing/ungrabbing the second mouse, would it still report false values, i.e. would it still be controlled by vusb?

[dariusd]

For a passed-through mouse, it should report exactly as it does on a physical host... vusb is simply passing through the device's packets, and will not tamper with them along the way.

--

Darius

[Mits2020]

Thanks for everything Darius.. another great idea went to the dumpster 😕

[banackm]

Yeah, Darius is right that this is probably an application that was written to expect relative mouse movements (ie (dx,dy)) from a standard desktop mouse, and doesn't handle absolute positions (ie (x,y)) from a tablet/touch-screen well, and VMware by default uses the absolute-style interface so that your mouse behavior more closely matches your host.

There should be a UI option for:

Edit -> Preferences -> Input -> "Optimize Mouse for Games" that you can set to "Always"

Which enables a feature we call "Gaming Mouse", that forces us to use the relative mouse mode and usually fixes most application issues like this.

A USB-passthrough mouse, as suggested by Darius, is another option, although I believe it requires some additional config options to enable, and you'd need to have an extra mouse on your desktop that was dedicated to the VM.  (I can probably dig those up if you want to try that, but that's not my recommendation.)

I wouldn't start disabling specific interfaces on your USB mouse though, as we have other ways of sending absolute events to the guest, and you're more likely to leave your guest in a weird state where we're unable to send mouse events.  So I'd remove the mouse.vusb.absDisabled options you set before enabling Gaming Mouse, particularly if it didn't work for you.

[wila]

Not understanding why "that idea when to the dumpster".

Doesn't that work just exactly as you requested?

Only downside is having an extra mouse?

--

Wil

[Mits2020]

I am not the OP - we have to wait for jeffpalnoseworthy​  to disclose his results. What I understood from the replies so far is that there is expected no difference between the main and an additional pointing device.

[jeffpalnosewort]

We ended up changing our application and the way it captures mouse movement. Thanks all for your help