Bug 456008 - Plasma VMWare host integration broken in 5.25
Summary: Plasma VMWare host integration broken in 5.25
Status: RESOLVED UPSTREAM
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.25.1
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://github.com/vmware/open-vm-too...
Keywords:
Depends on:
Blocks:
 
Reported: 2022-06-27 09:01 UTC by axel_kellermann
Modified: 2022-07-21 14:15 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description axel_kellermann 2022-06-27 09:01:36 UTC
SUMMARY
***
Since the update to Plasma 5.25 VMWare host integration isn't working anymore. Previously I was able to drag and drop files to/from the Windows host and exchange copy/pasted data via the clipboard. With 5.25 both mechanisms stopped working.
If I try to drag files from Plasma to Windows, it fails because the mouse pointer can't be moved beyond the Plasma desktop borders anymore. From Windows to Plasma the the mouse pointer just indicates that a drop operation into the Plasma desktop area isn't possible.
Similarly, copy/pasting clipboard content worked in both directions up until 5.24.5 and is broken now.
***


STEPS TO REPRODUCE
1. Just drag a file from Dolphin to e.g. the Windows desktop or an Explorer window
2. Or copy some text into the clipboard and try to paste it into and application on Windows

OBSERVED RESULT
Files can't be dragged beyond the Plasma desktop borders anymore, both on X11 and Wayland. File drags from Windows host are indicated as not possible by mouse pointer symbol.
Copy/pasting of text via clipboard doesn't work in either direction anymore.

EXPECTED RESULT
Drag and drop of files works as before and copy/paste of clipboard content is possible again (I used it daily up until 5.24.5).

SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 5.25.1
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.5
Kernel Version: 5.18.6-arch1-1 (64-bit)
Graphics Platform: X11
Graphics Processor: SVGA3D; build: RELEASE; LLVM;
Manufacturer: VMware, Inc.
Product Name: VMware Virtual Platform

ADDITIONAL INFORMATION
I'm running Arch Linux in the VM, host integration was installed via package open-vm-tools.
Comment 1 axel_kellermann 2022-06-27 09:33:09 UTC
SOFTWARE/OS VERSIONS
Host Operating System: Windows 10 20H2
Comment 2 Brennan Kinney 2022-07-09 03:50:34 UTC
Upstream issue: https://github.com/vmware/open-vm-tools/issues/568

Plasma 5.25 switched to systemd startup by default, which is partly the cause.

You need to either opt-out of that change, or have open-vm-tools package apply the same fix that openSUSE Tumbleweed is using.

---

> Similarly, copy/pasting clipboard content worked in both directions up until 5.24.5 and is broken now.

This is due to Plasma 5.25 switching by default to [systemd startup](https://invent.kde.org/plasma/plasma-workspace/-/wikis/Plasma-and-the-systemd-boot) and the VMware autostart not completing within the 5 second timeout AFAIK.

I used VMware to test KDE 5.25 on EndeavourOS (Arch based), Fedora 36 and openSUSE Tumbleweed. I found that Tumbleweed was unaffected and looked into why, they've wrapped the `vmware-user-suid-wrapper` autostart command with a script that exits early when systemd is detected from what I can tell.  I don't quite understand why it fixes (or works around) the issue, but it does.

You can apply it to your guest VM and it will work (_although updates may overwrite it later?_). I've detailed my findings (with the script) to the upstream issue for [`open-vm-tools`](https://github.com/vmware/open-vm-tools/issues/568#issuecomment-1178736806). I assume the maintainers must fix it there for other distro packages to pick up?

Alternatively, you can choose to [opt-out of the systemd startup feature as instructed by the ArchWiki section](https://wiki.archlinux.org/title/KDE#systemd_startup):

    kwriteconfig5 --file startkderc --group General --key systemdBoot false

---

> If I try to drag files from Plasma to Windows, it fails because the mouse pointer can't be moved beyond the Plasma desktop borders anymore.

After the above fix is applied this no longer happens. Although presently transferring from guest to host Dolphin windows, I'm getting an error about the file not existing.

It is successfully transferred to the cache directory (there's also a related folder in `/tmp` with symlinks to this location):

    /home/my-user/.cache/vmware/drag_and_drop
    /tmp/VMwareDnD

> From Windows to Plasma the the mouse pointer just indicates that a drop operation into the Plasma desktop area isn't possible.

Host to Guest transfers are working correctly with the fix however.

---

So technically not a Plasma bug?

The [systemd startup wiki entry](https://invent.kde.org/plasma/plasma-workspace/-/wikis/Plasma-and-the-systemd-boot) from David Edmundson does request including systemd in the summary:

> If you find a new bug, please include "systemd" somewhere in the summary, and report to the relevant place. I have a search set up on that title.

But I don't think bugzilla allows for editing comments unfortunately to update that.
Comment 3 axel_kellermann 2022-07-11 08:23:53 UTC
Thank you so much for the detailed explanation and the link to the workaround! Using a VM without clipboard and dnd is a real hassle. :)

And you are right, even I as the reporter can't edit the description. That's unfortunate.
Comment 4 axel_kellermann 2022-07-21 08:00:29 UTC
Bug is upstream, see  https://github.com/vmware/open-vm-tools/issues/568.
Comment 5 Nate Graham 2022-07-21 14:15:38 UTC
Thanks for following up!