VirtualPS/2 mouse not being presented

[deeplow]

Describe the bug

I am trying to run Qubes OS (Xen-based / Fedora as management guest) on VMWare. The main issue is that the mouse doesn't work on via ESXi's web UI. However, it works on other Linux (Debian and Fedora). It does click left and right, but not move around.

I should also note that open-vm-tools wasn't installed by default. So I had to install it (version 12.3.5) and manually set some parameters. I can confirm that open-vm-tools is successfully being detected because changing the window size does work and disabling vmtoolsd service breaks that scaling.

Reproduction steps

1. Setup VMware with Qubes OS 4.2.2 (enabling virtualization options + IOMMU)
2. Installing open-vm-tools in dom0 (Fedora) with `sudo qubes-dom0-update open-vm-tools
3. Set up vm settings like so:

Expected behavior

Mouse movements work.

Additional context

One difference I see on OSes where it works is that there are two new devices (VirtualPS/2 mouse) that doesn't get listed on Qubes OS (where it doesn't work). One of these mice is the one that correctly works (I checked with evtest). So I wonder what could be causing these virtual devices not to show up.

Some extra context can be found here: freedomofpress/securedrop-workstation-ci#61

[jonathanvmw]

@deeplow Thank you for reporting this issue. An internal bug report has been filed.

[jonathanvmw]

@deeplow Here's a comment I got from one of our developers:

To work with the ESXi web console, they either need the vmmouse Linux driver (which is not part of open-vm-tools, but a separate X11 driver package on their distro), or they need to attach a USB controller so that we can use a virtual USB mouse.

The web console only gets absolute mouse positions, and we can't inject that into the Guest without the proper mouse device.

Alternatively, if they use VMRC to connect to the VM, it does support relative mice, and might work if we're guessing the problem correctly.

[deeplow]

That is useful. I will investigate the driver situation.

[deeplow]

To work with the ESXi web console [...] they need to attach a USB controller so that we can use a virtual USB mouse.

In the past I have tried to go with this route, but using evtest did not yield any output from mouse movements on the USB devices. And since this was the case in virtualized systems where the mouse was working and where it was, I concluded that the USB controller option wouldn't be worth exploring right now.

To work with the ESXi web console, they either need the vmmouse Linux driver (which is not part of open-vm-tools, but a separate X11 driver package on their distro), or they need to attach a USB controller so that we can use a virtual USB mouse.

For the vmmouse linux driver, I looked briefly into this and unfortunately this doesn't seem to be packaged for fedora (it stopped after fedora 24). However, looking a system running fedora 40 with Xorg, where the mouse does work, I can see in the logs that it is using libinput for the VirtualPS/2 mouse just fine (event2 is the mouse):

So my current assessment is still the same as in the initial report:

One difference I see on OSes where it works is that there are two new devices (VirtualPS/2 mouse) that doesn't get listed on Qubes OS (where it doesn't work). One of these mice is the one that correctly works (I checked with evtest). So I wonder what could be causing these virtual devices not to show up.

However, I am still unsure what could cause different devices to be presented on different OSes. I don't know if this is still in open-vm-tools territory or if it's a VMWare issue.

As an additional factor, I did find a bug report from many years ago which has the exact same symptoms. But in our case, I think the issue goes deeper given that in systems where the mouse movement does not work evtest does not even detect input. Whereas in the bug report, I believe it does, it's just that it was interpreting the inputs wrongly (relative positions as opposed to absolute ones).

[jonathanvmw]

@deeplow - Here's the response from the developer.

In the past I have tried to go with this route, but using evtest did not yield any output from mouse movements on the USB devices. And since this was the case in virtualized systems where the mouse was working and where it was, I concluded that the USB controller option wouldn't be worth exploring right now.

He should attach a USB controller, so we attach a virtual USB mouse. He should also ensure that his GuestOS has an appropriate driver for a generic HID mouse. We will choose which mouse device to use based the type of mouse input, and a variety of other GuestOS/activity heuristics, but if there's no USB controller we lose this avenue for sending virtual mouse events. Depending on your GuestOS configuration, the virtual USB mouse might be the only way we have to send absolute mouse events.

For the vmmouse linux driver, I looked briefly into this and unfortunately this doesn't seem to be packaged for fedora
(it stopped after fedora 24). However, looking a system running fedora 40 with Xorg, where the mouse does work, I can
see in the logs that it is using libinput for the VirtualPS/2 mouse just fine (event2 is the mouse):

Newer Linux distros use the in-kernel vmmouse driver (eg Linux option CONFIG_MOUSE_PS2_VMMOUSE ), and newer version of Xorg will use that. He should ensure his Guest kernel has CONFIG_MOUSE_PS2_VMMOUSE, and/or that the older Xorg vmmouse driver is installed.

However, I am still unsure what could cause different devices to be presented on different OSes.

The virtual PS/2 mouse is always present, unless he specifically turned it off via custom VMX file settings. If it's not getting listed in the Guest OS, then he has a missing driver or GuestOS configuration problem.