SUMMARY In a Wayland multi-monitor setup where the non-primary screen is to the _left_ of the primary screen ("extend to the left"), the content is overlapped into the primary screen. In ASCII art, for * left non-primary == 2.5K resolution * primary == 4K resolution this looks like ``` +---------------------+--------+ | <left non-primary> | | |---------------------+ | | | | <primary> | +------------------------------| ``` Extending to the right works as expected. This also holds true for a triple monitor setup, where one screen extends to the left and one screen extends to the right of the primary screen. "Display Configuration" shows the intended (correct) layout. This may be an artefact of running KDE Plasma 6 b2+ (git master) under VMware Workstation / vmwgfx with `export KWIN_DRM_NO_AMS=0` STEPS TO REPRODUCE 1. create a multi-monitor setup 2. "physically" place at least one screen to the left of the primary screen 3. use "Display Configuration" to assert that physical left screen is logically placed to extend the primary screen to the left (i.e. vertically aligned at the top, offset to the left by resolution of secondary screen) OBSERVED RESULT Left screen overlaps primary screen as in ASCII art diagram above. EXPECTED RESULT Left screen extends desktop to the left.
Created attachment 164616 [details] drm_info in broken state (left-extend not working)
Created attachment 164617 [details] drm_info in working state (right-extend working well)
Attached drm_info dumps where VMware Workstation adds the monitor "to the left" and "to the right", respectively, where KDE Desktop Configuration matches the extend intent exactly * left-extend == 2.5k screen physically (and mapped through host) to the left * right-extend == 3k laptop screen physically (and mapped through the host) to the right Center screen is always the 4k screen.
FWIW, and possibly a separate challenge: Take the working "extend to the right" setup from above and move the secondary screen to _extend to the bottom_. This does not render correctly, either (fair enough - see above). Do note that the mouse cursor now moves "in an unnatural fashion" - it feels as if some unsuitable mouse acceleration profile is being applied.
No difference in behaviour with KWIN_DRM_NO_AMS _not_ set - right now (on my kernel) this implies no atomic mode-setting.
The matching Fedora Rawhide (40) GNOME setup, which runs in legacy mode (no atomic mode-setting) exposes the exact same behavior as KDE Plasma 6 b2+ (git master) on Wayland. To that extent, there may be a commonality to the multi-monitor Wayland driving of GNOME and KDE Plasma 6 on Fedora Rawhide (40). Additional data point: I also tried KDE Plasma 5.27.10 in an X11 session on Arch Linux, with the same virtual graphics "hardware" setup and with legacy mode setting. In that X11 environment, the screens both left-extend and right-extend correctly for rendering (this was also working previously on F39, do not have this infra at the moment). Note that that the KDE X11 setup has challenges in cursor to (virtual) screen mapping though - but those can be fixed by running a script that uses kscreen-doctor to "re-layout" the screens in a different sequence (cf https://github.com/vmware/open-vm-tools/issues/484#issuecomment-1703922094. So, in theory, given the above, one could argue that Wayland KDE Plasma 6 has regressed relative to X11 KDE Plasma 5.27.10.
Created attachment 164618 [details] X11 5.27 left-extend working
Created attachment 164619 [details] drm_info with legacy mode setting in broken state (left-extend not working)
Created attachment 164620 [details] Left 6.0 Wayland (broken) <-> Right X11 5.27 (working) Attached a screenshot which shows the material difference(s) between the working X11 setup on Plasma 5.27 and the equivalent non-working Wayland setup on Plasma 6 b2+. Fundamentally, * on X11 (right side), there is one backing framebuffer with size 6400x2160 covering both active planes (with offsetting via the SRC_X property) * on Wayland (left side), there are two distinct framebuffers, one for each plane, each of the "right size", and each at SRC_X == 0.
If the VM driver abuses the complete non-information of framebuffer SRC properties to infer monitor layouts, then that's frankly something that *really* has to be fixed in the VM driver. We will not add workarounds for that.