https://bugs.kde.org/show_bug.cgi?id=456008
Brennan Kinney <polarathene-sig...@hotmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |polarathene-signup@hotmail.
| |com
Ever confirmed|0 |1
Status|REPORTED |CONFIRMED
--- Comment #2 from Brennan Kinney <polarathene-sig...@hotmail.com> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
