Mouse clicks on wrong monitor with specific multi-monitor layout

[shoffmeister]

Mouse clicks will be registered on the wrong (virtual) monitor if the host has a peculiar multi-monitor layout.

Guest: Fedora 33 (open-vm-tools 11.2.0) with KDE / X Host: Windows 10 and VMware Workstation Player 15.5.6, multi-monitor setup enabled

Two monitors, lets call them "1 = laptop" and "2 = external", are attached to the host.

A "natural" multi-monitor layout in such a case would be "1" on the left, "2" extending to the right (both physically and configured in Windows). In this natural layout, mouse clicks inside the virtual machine will register at exactly the right location - i.e. clicks (left/right) on monitor "2" will be registered on monitor "2", at the right coordinate. Good.

This breaks down in a more specific layout configuration, where monitor "2" extends to the left of monitor "1" - physically, but also configured exactly this way in Windows display settings. With this in place, clicks on monitor "2" end up on monitor "1" (and vice versa). And it is only clicks (i.e. the cursor position) which apparently are lacking some coordinate system translation.

FWIW, I do know that the native setup handles this exact scenario correctly, so it is the virtualization stack which (somewhere) has challenges in coordinate translation.

I'll be happy to report elsewhere, but please do let me know where.

[shoffmeister]

For visual reference, and to clarify the monitor layout / arrangement on Windows 10:

[anilnambiar]

Thanks for reporting this issue. We have filed a bug internally for investigation. Can you let us know if it was working for you before and recently broke or is this the first time you are trying this layout and found it broken?

[shoffmeister]

Regrettably, I cannot tell whether this is a regression.

FWIW, I do believe that I saw the exact same issue not only with VMware Workstation Player, but also also with VirtualBox (current) - all other things being equal. This makes me believe that this is either on the guest side, or on the protocol side between guest and host.

I flipped to VMware Workstation Player simply because it is the better product (plus having used VMware developer virtualization products for an eternity) and it became available to me through my enterprise organization.

[anilnambiar]

Thanks for the details.

[hagfelsh]

This particular problem seems to be present still. In my case, it's with three monitors: left, middle, right.

All clicking in left interacts with middle, and all middles interact with right.

A dual monitor (middle, right) works just as expected.

Workstation 16 Pro 16.1.2 build-17966106 Host: Windows 10 VM: Ubuntu 20.04.5 + KDE open-vm-tools 11.3.0

[rprabhud]

@hagfelsh I checked the internal bug used for this investigation. The bug is closed as it is not a bug but user error. As suggested in the bug, you need to map the mouse to the display you want to. You might need to try following steps in the terminal opened inside the vm: 1) Run command 'xinput', note the device id . e.g. VirtualPS/2 VMware VMMouse id=10 2) Run command 'xrandr' and note the output device. e.g. Virtual1 connected primary 1071x843+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 3) Run command: xinput map-to-output

e.g xinput map-to-output 10 Virtual1

Hope this helps. Thanks.

[shoffmeister]

to the display - how do we find "the" display in a multi-monitor setup, comprising, of one screen 1024x768 and one screen 3092x1600 (or watever)?

[kiwimato]

@hagfelsh I have the same issue, but I'm running the host on Linux.

Latest Workstation 16.2.1 build-18811642 Host: Manjaro Linux + KDE VM: Manjaro Linux + KDE open-vm-tools: 11.3.5-1

I think it this could be an issue of the KDE + open-vm-tools combo, because I noticed that the same issue does not exist in Gnome, however I don't have the issue in my host either where I also run KDE, even though I had it at some point, I can't reproduce it on the host anymore.

Trying to screenshot the issue I realized one thing: Flameshot, the screenshot software sees my monitors swapped. In reality, the monitor with the blue selection rectangle is on the right and the red circles show the location of the actual mouse cursor.

PS: Opened a bug report with KDE here

[Rapti]

Having the same issue. My company laptop runs an Oracle Linux guest on a Windows host. The Linux guest came with Gnome. Personally not being a huge fan of Gnome, I went ahead and installed Plasma and ran into this issue. I don't have any problems like this when using Gnome in the VM or when using Plasma on my home computer without a VM.

When I open Plasma's settings, I'll find that the monitor arrangement shown there is the wrong way around: The monitor that is actually on the left is shown on the right and vice versa. The monitor setup is correctly configured on the Windows host, and I'm using the "choose a monitor layout" dropdown in VMware. After rearranging the monitors in Plasma to match the layout configured in Windows, everything works fine, but this can be quite tricky as I can't see where I actually need to click.

So the problem seems to arise from the combination of VMware and Plasma, as both work fine on their own. It's possible that this needs to be fixed on KDE's end rather than VMware's, but I certainly wouldn't call this "user error".

[kiwimato]

@Rapti as a workaround I found that by opening Display Configuration in KDE in all cases the monitors are slightly misaligned, or simply swapped. It does get a bit of point an clicking around because by this point you will click on an empty monitor to trigger something on the correct screen, but if you do this properly, and swap the monitors for example, it will fix the issue.

Sometimes I also had the issue when the click was slightly off, and in that case just slightly moving one of the monitors fixed it. I get it ocasionally, for some reason KDE simply forgets the configuration every X weeks and I have to do this again. Also I noticed that always opening VMWare on the same host screen first matters, as moving it to another screen on next boot will cause this thing to get triggered again.

Good luck!

[Rapti]

You might need to try following steps in the terminal opened inside the vm:

1. Run command 'xinput', note the device id .
   e.g.  VirtualPS/2 VMware VMMouse    id=10

2. Run command 'xrandr' and note the output device.
   e.g.  Virtual1 connected primary 1071x843+0+0 (normal left inverted right x axis y axis) 0mm x 0mm

3. Run command:  xinput map-to-output  
   e.g  xinput map-to-output 10 Virtual1

This maps the entire span across all monitors to a single monitor. Clicking on the left side of the left monitor will send a click to the left side of Virtual1, while clicking on the right side of the right monitor will click on the right side of Virtual1 as well. It becomes impossible to send clicks to any other monitor. Definitely not what I (or anyone else here) is looking for.

@Rapti as a workaround I found that by opening Display Configuration in KDE in all cases the monitors are slightly misaligned, or simply swapped. It does get a bit of point an clicking around because by this point you will click on an empty monitor to trigger something on the correct screen, but if you do this properly, and swap the monitors for example, it will fix the issue.

Thanks, but this is is exactly what I did. It is very tedious, especially when the monitors have different sizes and pixel densities. I just hope there's a better solution.

[ejurga]

I have this exact problem as well. I am running Arch with an Xorg and i3 however, so I don't think this is a specific problem with Plasma.

[shoffmeister]

Having successfully avoided multi-monitor virtual machines for a long time, I am now back to this problem.

The hacky script below is designed to configure a working multi-monitor KDE environment such that the mouse actually works.

Requirements:

• KDE with kscreen-doctor
• jq

Usage:

• run the script without any parameters and it will provide a list of screens
• run the script with a monitor order from left to right - and the script will set that up as instructed

Example: the-script 1 2 arranges virtual screen 1 left most, then the next screen tacked on towards the right.

Things get funky because the-script 3 1 2 can be quite a valid choice, depending on many physical screens you have, how they are wired up, and from which physical screen you went into VMware full-screen mode (the VMware driver will dish out the same names, just the screens in different order)

In essence you will need to learn the right sequence of numbers for "your current scenario" by trial&error. KDE is totally happy with this flip flop and choosing between the-script 1 2 and the-script 2 1 should be simple enough.

The script has been tested successfully with a three screen heterogenous multi-monitor setup.

#!/usr/bin/env bash

set -e
set +x

outputs=$(kscreen-doctor --json | jq ' 
[ 
    .outputs[] 
    | select(.connected == true) 
    | select(.enabled == true) 
    | .name as $name
    | .currentModeId as $currentModeId
    | .modes[] | select(.id == $currentModeId ) as $mode
    | $mode.size.width as $width
    | { name: $name, width: $width } 
] ')

echo "
Identified outputs:
---
$outputs
---
"

if [[ $# -eq 0 ]]; then
  exit 0
fi

#
# TODO add input sanity checking
# This trusts the user to put in the right count of
# digits in, so that they make up a useful sequence
# of outputs.
#

declare -a kdoctor_outputs=()
xpos=0
for index in "${@}"; do
    screen_name="Virtual${index}"
    output_width=$(echo "${outputs}" | jq -r --arg screen_name "${screen_name}" ' .[] | select(.name==$screen_name).width ')

    # echo "${screen_name}: ${output_width}"

    kdoctor_outputs+=("output.${screen_name}.position.${xpos},0")
    xpos=$((xpos+output_width))
done

echo "Running kscreen-doctor with the following outputs:
  ${kdoctor_outputs[*]}
"

# This will generate calls such as
#   kscreen-doctor output.Virtual2.position.0,0 output.Virtual1.position.1920,0
#   kscreen-doctor output.Virtual1.position.0,0 output.Virtual2.position.1920,0
# as appropriate
kscreen-doctor "${kdoctor_outputs[@]}"