Bug 407058

I've been having the same problem with VMware Workstation 15.0.4 and guest OSes that use KDE with Plasma 5.15:
KDE Neon 18.04
Kubuntu 18.04
Manjaro KDE

I used to be able to change the resolution in the above distributions but now they are stuck in 800x600.
The bug doesn't happen with Kali 2019.1 KDE (Plasma 5.14.5).

As an FYI, situation unchanged with 5.16 (tested on Neon)

I'm having the same issue with VirtualBox 6.0.10 using the VMSVGA controller. Since that's a VMWare display adapter, I think it's the same issue.

Arch Linux 5.2.11
Qt 5.13.0
Plasma 5.16.4
Frameworks 5.61.0

To sanity test, I tried installing GNOME and had no issues, so it's not a driver or OS issue.

The bug still happens as of 2019-09-03 with the latest version of KDE and VMWare (v15.1.0).
Operating System: KDE neon 5.16
KDE Plasma Version: 5.16.5
KDE Frameworks Version: 5.61.0
Qt Version: 5.12.3
Kernel Version: 4.15.0-60-generic
OS Type: 64-bit

Yes, 5+ months and things are unchanged. It was confirmed, but no other comments if or when this might be worked on. Don't know what changed with 5.15 and going on with 5.16, which might have caused this.

Tested with latest Arch and Neon.

If there is anything else we can provide / help with to get this resolved, please let us know.

Just updated to 5.17 and situation continues to be unchanged.

This bug seems to be somewhat fixed in 5.17.2 as of 2019-11-07.  I can resize the VMWare window which will then automatically resize the guest OS desktop.  Using the Display Configuration within the guest OS does not work though; it will have the same bug as before where it tries to change the resolution for a split second and then go back to the previous resolution.

Operating System: KDE neon 5.17
KDE Plasma Version: 5.17.2
KDE Frameworks Version: 5.63.0
Qt Version: 5.13.1
Kernel Version: 4.15.0-66-generic
OS Type: 64-bit

Created attachment 123817 [details]
KDE Neon in VMware

This bug actually prevents me from trying out KDE Neon in a virtual machine.
A resolution of 800x600 is too small for the installer which means the "Next" button is missing, which means I cannot finish (or even start) the install.

See here:
https://ibb.co/hXR04Hf

(In reply to Dries Dokter from comment #9)
> This bug actually prevents me from trying out KDE Neon in a virtual machine.
> A resolution of 800x600 is too small for the installer which means the
> "Next" button is missing, which means I cannot finish (or even start) the
> install.
> 
> See here:
> https://ibb.co/hXR04Hf


Can you work around the issue by holding the ALT key and using the left mouse the click and drag the window to the left so you can see the Next button to install?

(In reply to Dries Dokter from comment #9)
> This bug actually prevents me from trying out KDE Neon in a virtual machine.
> A resolution of 800x600 is too small for the installer which means the
> "Next" button is missing, which means I cannot finish (or even start) the
> install.
> 
> See here:
> https://ibb.co/hXR04Hf

You can drag the window to the left, which then exposes the buttons so you can continue. Not ideal, but at least a work around.

Created attachment 123863 [details]
attachment-31429-0.html

I know that I can do that, but wanted to  show that this is the first
problem that I encountered when trying out KDE NEON.
It appears this has little to no priority

On Tue, Nov 12, 2019 at 12:15 PM <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=407058
>
> --- Comment #11 from bighuskysf@outlook.com ---
> (In reply to Dries Dokter from comment #9)
> > This bug actually prevents me from trying out KDE Neon in a virtual
> machine.
> > A resolution of 800x600 is too small for the installer which means the
> > "Next" button is missing, which means I cannot finish (or even start) the
> > install.
> >
> > See here:
> > https://ibb.co/hXR04Hf
>
> You can drag the window to the left, which then exposes the buttons so you
> can
> continue. Not ideal, but at least a work around.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

(In reply to Dries Dokter from comment #12)
> Created attachment 123863 [details]
> attachment-31429-0.html
> 
> I know that I can do that, but wanted to  show that this is the first
> problem that I encountered when trying out KDE NEON.
> It appears this has little to no priority
> 

Yup, sadly fully agree and can't fix it myself.

System: Apple Macbook 12” (2017)
OS: macOS Mojave 10.14.6
VM software: VMware Fusion 11.5.1

Doing some Kubuntu testing, test case #1: Kubuntu 19.10 - “Try Kubuntu” (live disk)

It is in 800x600 and the resolution can’t be changed via System Settings (it snaps back to 800x600 after a second as previously described). 

Fixed by: sudo apt install open-vm-tools

which sets the VM to a usable 1280x800 resolution. However, the bug still exists as the resolution still can’t be changed by System Settings: it will now snap back to 1280x800 if you try to change it.

-----

Test case #2: Kubuntu 19.10 - “Install Kubuntu”

The installer starts in 800x600 which makes selections difficult, but as soon as installer gets past the “Updates and Other Software" screen and Kubuntu's under-the-covers open-vm-tools kick in the screen becomes a usable resolution and this is “permanent” as the installed VM stays at this resolution even through reboots.

I can even enable “Use full resolution for Retina display” in VMware Fusion and get a 2560x1600 resolution in the VM. I then set the scaling in System Settings to 2 for a beautiful, usable HiDPI VM.

Still, the 2560x1600 can’t be altered via system settings, but since this is an optimal resolution I don’t really want to change it!

System: Apple Macbook 12” (2017)
OS: macOS Mojave 10.14.6
VM software: VMware Fusion 11.5.1

More testing. I have an existing Manjaro KDE VM:

KDE Plasma: 5.17.4
KDE Frameworks: 5.64.0
Qt Version: 5.13.2
Kernel Version: 5.4.2-1-MANJARO
OS Type: 64-bit

that ehibits this (800x600) on every boot. My notes from this summer indicate a workaround. To fix in-session, do:

systemctl stop vmtoolsd.service
systemctl start vmtoolsd.service

To fix it "for good," edit:

/usr/lib/systemd/system/vmtoolsd.service

adding:

After=display-manager.service

At the end of the [Unit] section.

Then resolutions (including HiDPI) can be set as usual. The in-session fix still works and could probably be scripted, but the “permanent” fix above only works sometimes! It failed all today day and then when I rebooted just now it worked again. Sigh.

The above workarounds and “fixes” are from a discussion of the bug in the Manjaro forums: https://forum.manjaro.org/t/vmware-cant-change-screen-resolution/89090

This would seem to be a bug at the intersection of Plasma, VMware and Open VM Tools. Hope these data points help in some way.

(In reply to Ralf from comment #15)
> System: Apple Macbook 12” (2017)
> OS: macOS Mojave 10.14.6
> VM software: VMware Fusion 11.5.1
> 
> More testing. I have an existing Manjaro KDE VM:
> 
> KDE Plasma: 5.17.4
> KDE Frameworks: 5.64.0
> Qt Version: 5.13.2
> Kernel Version: 5.4.2-1-MANJARO
> OS Type: 64-bit
> 
> that ehibits this (800x600) on every boot. My notes from this summer
> indicate a workaround. To fix in-session, do:
> 
> systemctl stop vmtoolsd.service
> systemctl start vmtoolsd.service
> 
> To fix it "for good," edit:
> 
> /usr/lib/systemd/system/vmtoolsd.service
> 
> adding:
> 
> After=display-manager.service
> 
> At the end of the [Unit] section.
> 
> Then resolutions (including HiDPI) can be set as usual. The in-session fix
> still works and could probably be scripted, but the “permanent” fix above
> only works sometimes! It failed all today day and then when I rebooted just
> now it worked again. Sigh.
> 
> The above workarounds and “fixes” are from a discussion of the bug in the
> Manjaro forums:
> https://forum.manjaro.org/t/vmware-cant-change-screen-resolution/89090
> 
> This would seem to be a bug at the intersection of Plasma, VMware and Open
> VM Tools. Hope these data points help in some way.

On Arch with all the latest updates, the systemctl stop vmtoolsd.service and systemctl start vmtoolsd.service did not change the behavior. changing the resolution afterwards to anything and apply, works for a second and then reverts back to 800x600

Going to try editing the file. Also going to try the latest Neon, as it also failed previously, even after installing the open-vm-tools package.

(In reply to bighuskysf from comment #16)
> (In reply to Ralf from comment #15)
> > System: Apple Macbook 12” (2017)
> > OS: macOS Mojave 10.14.6
> > VM software: VMware Fusion 11.5.1
> > 
> > More testing. I have an existing Manjaro KDE VM:
> > 
> > KDE Plasma: 5.17.4
> > KDE Frameworks: 5.64.0
> > Qt Version: 5.13.2
> > Kernel Version: 5.4.2-1-MANJARO
> > OS Type: 64-bit
> > 
> > that ehibits this (800x600) on every boot. My notes from this summer
> > indicate a workaround. To fix in-session, do:
> > 
> > systemctl stop vmtoolsd.service
> > systemctl start vmtoolsd.service
> > 
> > To fix it "for good," edit:
> > 
> > /usr/lib/systemd/system/vmtoolsd.service
> > 
> > adding:
> > 
> > After=display-manager.service
> > 
> > At the end of the [Unit] section.
> > 
> > Then resolutions (including HiDPI) can be set as usual. The in-session fix
> > still works and could probably be scripted, but the “permanent” fix above
> > only works sometimes! It failed all today day and then when I rebooted just
> > now it worked again. Sigh.
> > 
> > The above workarounds and “fixes” are from a discussion of the bug in the
> > Manjaro forums:
> > https://forum.manjaro.org/t/vmware-cant-change-screen-resolution/89090
> > 
> > This would seem to be a bug at the intersection of Plasma, VMware and Open
> > VM Tools. Hope these data points help in some way.
> 
> On Arch with all the latest updates, the systemctl stop vmtoolsd.service and
> systemctl start vmtoolsd.service did not change the behavior. changing the
> resolution afterwards to anything and apply, works for a second and then
> reverts back to 800x600
> 
> Going to try editing the file. Also going to try the latest Neon, as it also
> failed previously, even after installing the open-vm-tools package.

Making the change to the file as suggested also made no difference on the current Arch install.

Just tested the latest KDE Neon with the latest beta of KDE Plasma 5.18 and sadly the issue/bug/behavior is still identical.
Really sad that this is not getting any attention. Had to drop using KDE under VMware. Can only use it under Virtualbox on personal laptop.
So far I don't see any sign of this getting any attention (with 3 major versions now exhibiting the issue).

Why this MAJOR bug is ignored?

Host: Oracle VirtualBox 6.1.2 r135662 (Qt5.6.2) on Windows 7 X64
In VM settings as graphics controller is selected: VMSVGA (which is preferred for Linux guests):

lspci -nnk | grep -i vga -A2
00:02.0 VGA compatible controller [0300]: VMware SVGA II Adapter [15ad:0405]
	Subsystem: VMware SVGA II Adapter [15ad:0405]
	Kernel driver in use: vmwgfx
	Kernel modules: vmwgfx

Guest 1:
openSUSE Tumbleweed 20200118
Plasma ver.: 5.17.5
KDE Frameworks: 5.66.0
Qt ver.: 5.13.1
Kernel: 5.4.10-1-default
Arch: 64-bit

Guest 2:
Fedora 31 KDE Plasma
Plasma ver.: 5.17.5
KDE Frameworks: 5.64.0
Qt ver.: 5.13.2
Kernel: 5.3.7-301.fc31.x86_64
Arch: 64-bit

and another Plasma distros like KDE Neon 5.17 etc.

Same issue - cannot change resolution from GUI (systemsettings5) or from terminal emulator with "xrandr" command.

Situation unchanged with latest 5.18.3 release and also on latest vmware fusion 11.5.2

*** Bug 415648 has been marked as a duplicate of this bug. ***

*** Bug 420169 has been marked as a duplicate of this bug. ***

Here is a trick for this bug on hypervisor QEMU with QXL video :
with the systemd spice-vdagentd (service and socket), the resolution can be set automatically to fit the window of the host though not possible via system settings or xrandr.
this trick works at arbitrary resolution up to my fullscreen 1920x1080.

However, reading #420169, #407058 and #415648, this issue is quite serious for VMs, reaching many KDE for VMware, VirtualBox and Qemu, one might consider changing priority ? For kubuntu 20.04LTS, expected 23 april, I guess it will be too late.
Please let me know if you need my support to test on QEMU.

lspci  -nnk  |   grep VGA -A 3
00:02.0 VGA compatible controller [0300]: Red Hat, Inc. QXL paravirtual graphic card [1b36:0100] (rev 04)
        Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
        Kernel driver in use: qxl
        Kernel modules: qxl

Referring to some rather old notes...

Observed this with KVM, Fedora 29 KDE spin. As a workround was able to preset the screen size by creating a:

        /etc/X11/xorg.conf.d/50-monitor.conf

config file containing

        Section "Monitor"
            Identifier "Virtual-0"
            Option "PreferredMode" "1440x900"
        EndSection

This config option works for me with Fedora 30 and 31 KDE spins (as KVM host and guest)

With Neon: /usr/share/X11/xorg.conf.d/50-monitor.conf

(Was originally posted to Bug 420169)

Again with KVM (Fedora 30 and 31 KDE spins as host system, with Fedora 30, 31 and Neon as guests)

It is possible to change the Video setting for the KVM guest to be "Virtio" rather than "QXL".

It is then possible to change the size of the "Virtual 1" display in the guest.

That did not change the display size used by SDDM but was remembered once logged in...

(Was also originally posted to Bug 420169)

See also:
    https://old.reddit.com/r/kde/comments/g8bfeg/fyi_how_to_make_kde_plasma_work_at_resolutions/

Confirming this bug with KDE Neon 5.18 running as a VMware Workstation 15.5.2 guest.  With View | Autosize | Autofit Guest I can drag the VMware window and resize the KDE desktop with no issues.  I cannot find a combination of settings that will allow the guest to dictate the sizing.

My solution was to move /usr/lib/qt5/plugins/kf5/kscreen/ out of the way and restart.  Otherwise kscreen is criminally obsessed with 800x600.

kscreen-doctor says "followPreferredMode: true" ... is there a command to change that value to false?

Oracle VirtualBox forum rep literally told me to stop using KDE.  I don't understand the disdain between major projects here.

With vbox 6.1.9 (testing) + VMSVGA, it seems to work with:
KDE Settings -> Startup -> Background -> KScreen -> disable
This work-around is immediate and persistent.
Resizing then works both in guest and from host.
(openSUSE Tumbleweed + KDE 5.18.5 on Win10)

Someone said KDE 5.15 adjusted for Qemu, but that broke all other VMs.

the auto-resize seems to work when switching to Fullscreen via Host+F (default = Right Ctrl + F)

The problem seems to be with KScreen.

I followed Jason Mancini's Comment 31(posted on 2020-06-04 06:53:35 UTC) and it solved the problem for my PCLinuxos live ISO - pclinuxos64-kde5-2020.05.iso.

I disabled KScreen2 from Start Menu > Background Services > Startup Services and then I increase the display resolution from 800x600 and the change was persistent.
The resolution didn't immediately reset to 800x600 if KScreen2 is disabled. Even if KScreen2 is enabled but its Status is "Not Running", the resolution cannot be changed, so make sure to disable KScreen2.

I hope someone can fix this issue with Kscreen.

Thank you  Jason Mancini !

(In reply to kdeusr from comment #33)
> The problem seems to be with KScreen.
> 
> I followed Jason Mancini's Comment 31(posted on 2020-06-04 06:53:35 UTC) and
> it solved the problem for my PCLinuxos live ISO -
> pclinuxos64-kde5-2020.05.iso.
> 
> I disabled KScreen2 from Start Menu > Background Services > Startup Services
> and then I increased the display resolution from 800x600 and the change was
> persistent.
> The resolution didn't immediately reset to 800x600 if KScreen2 is disabled.
> Even if KScreen2 is enabled but its Status is "Not Running", the resolution
> cannot be changed, so make sure to disable KScreen2.
> 
> I hope someone can fix this issue with Kscreen.
> 
> Thank you  Jason Mancini !

I was using Virtualbox v6.0

I had the same issue. I took me some time to figure out that I have to use virtio instead of qxl in virt-manager. After the switch to virtio I was able to change the resolution. The performance of qxl was terrible, so this change is quite important. Maybe there should be a warning in KDE about qxl.

Operating System: Arch Linux
KDE Plasma Version: 5.20.3
KDE Frameworks Version: 5.76.0
Qt Version: 5.15.2
Kernel Version: 5.9.11-arch2-1
OS Type: 64-bit

The issue still continues all the way to 5.20.4

Only current 'work-around' is to disable kscreen2.
In addition sccm has to have an xrandr command to specify a desired size to prevent the always initial 800x600 resolution (regardless of what the previous resolution of the desktop was set to)

Updated version as can confirm on VirtualBox 6.1 with 5.20.4 Plasma, 5.10.2 kernel.

Can confirm with Plasma 5.20.5 in Virtualbox 6.1. Very annoying issue for using Plasma in a VM.

I found that it happens only on Wayland Plasma Session. On XOrg it works as expected

According to open-vm-tools development team(https://github.com/vmware/open-vm-tools/issues/493#issuecomment-775450550), they think it is because "KDE KWin wayland backend is not correctly responding to the CHANGE hotplug events on the drm subsystem; it should rescan the drm connectors and update modes. "

I have made some tests and the result depends on the environment.

I have a Linux host (openSUSE Tumbleweed 20210210; Plasma 5.20.5) and a
Windows host (Windows 10 20H2).
I tried both: VirtualBox 6.1.18 and VMware Workstation Pro 15.
VirtualBox offers VBoxSVGA and VMSVGA as display controller.

For the client I used again openSUSE Tumbleweed 20210210 (Plasma 5.20.5) and tested with all three display servers (Plasma X11, Wayland and Full Wayland).


Linux Host:
             |  VirtualBox 6.1.18
             |  VBoxSVGA | VMSVGA   
-------------+-------------------------
Plasma X11   |  applet   | applet fail
Wayland      |  applet   | applet
Full Wayland |  applet   | applet

Windows Host:
             |  VirtualBox 6.1.18       | Workstation Pro 15
             |  VBoxSVGA | VMSVGA       |
-------------+--------------------------+------------------
Plasma X11   | automatic | applet fail  | automatic
Wayland      | applet    | applet       | applet
Full Wayland | applet    | applet       | applet

Legend:
- applet:      resizing is only in the system settings possible
- applet fail: resizing is only in the system settings possible, but the 
               screen resolution  falls back to 800x600 in one second.
- automatic:   resizing is possible by changing the window. (=perfect)

All tests are made with a fresh client installation and default options. (without any further updates or package installations in the client)

(In reply to ZhangHua from comment #40)
> According to open-vm-tools development
> team(https://github.com/vmware/open-vm-tools/issues/493#issuecomment-
> 775450550), they think it is because "KDE KWin wayland backend is not
> correctly responding to the CHANGE hotplug events on the drm subsystem; it
> should rescan the drm connectors and update modes. "

I am working toward a patch serie to fix this.

This begins with the protocol :https://invent.kde.org/libraries/plasma-wayland-protocols/-/merge_requests/9

Then it will need KWin kwayland-server kwayland kcreen and libkscreen patchs.

This bug seems to be a mix of two things.

It not working in wayland, which was to be expected at the time

And it not working in X11 which were describing user setup issues.

Neither are very high regressions.

This issue is showing up in Fedora 34 KDE with Plasma Wayland with Plasma 5.22 on VMware Workstation 16 and VMware Fusion 11.

Reference downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1994174

Git commit 0a2c511489cf4cfa7216b3222cee0430ef9a829c by Méven Car, on behalf of Méven Car.
Committed on 01/09/2021 at 13:37.
Pushed by meven into branch 'master'.

Wayland: Add support for protocol kde-output-device_v2, allow to detect drm mode changes

M  +3    -6    autotests/integration/outputmanagement_test.cpp
M  +1    -1    src/CMakeLists.txt
M  +1    -1    src/abstract_output.cpp
M  +2    -2    src/abstract_output.h
M  +28   -12   src/abstract_wayland_output.cpp
M  +13   -3    src/abstract_wayland_output.h
M  +8    -11   src/platform.cpp
M  +2    -2    src/platform.h
M  +0    -5    src/plugins/platforms/drm/drm_abstract_output.h
M  +2    -2    src/plugins/platforms/drm/drm_backend.cpp
M  +2    -0    src/plugins/platforms/drm/drm_gpu.cpp
M  +17   -8    src/plugins/platforms/drm/drm_object_connector.cpp
M  +2    -0    src/plugins/platforms/drm/drm_object_connector.h
M  +48   -13   src/plugins/platforms/drm/drm_output.cpp
M  +6    -3    src/plugins/platforms/drm/drm_output.h
M  +1    -1    src/plugins/platforms/drm/drm_pipeline.cpp
M  +3    -4    src/plugins/platforms/drm/drm_virtual_output.cpp
M  +2    -2    src/plugins/platforms/drm/drm_virtual_output.h
M  +1    -1    src/plugins/platforms/drm/egl_stream_backend.cpp
M  +1    -1    src/plugins/platforms/drm/scene_qpainter_drm_backend.cpp
M  +1    -1    src/plugins/platforms/wayland/egl_wayland_backend.cpp
M  +6    -6    src/wayland_server.cpp
M  +2    -3    src/wayland_server.h
D  +0    -139  src/waylandoutputdevice.cpp
A  +152  -0    src/waylandoutputdevicev2.cpp     [License: GPL(v2.0+)]
R  +7    -3    src/waylandoutputdevicev2.h [from: src/waylandoutputdevice.h - 074% similarity]

https://invent.kde.org/plasma/kwin/commit/0a2c511489cf4cfa7216b3222cee0430ef9a829c

(In reply to Méven Car from comment #45)
> Git commit 0a2c511489cf4cfa7216b3222cee0430ef9a829c by Méven Car, on behalf
> of Méven Car.
> Committed on 01/09/2021 at 13:37.
> Pushed by meven into branch 'master'.
> 
> Wayland: Add support for protocol kde-output-device_v2, allow to detect drm
> mode changes
> 
> M  +3    -6    autotests/integration/outputmanagement_test.cpp
> M  +1    -1    src/CMakeLists.txt
> M  +1    -1    src/abstract_output.cpp
> M  +2    -2    src/abstract_output.h
> M  +28   -12   src/abstract_wayland_output.cpp
> M  +13   -3    src/abstract_wayland_output.h
> M  +8    -11   src/platform.cpp
> M  +2    -2    src/platform.h
> M  +0    -5    src/plugins/platforms/drm/drm_abstract_output.h
> M  +2    -2    src/plugins/platforms/drm/drm_backend.cpp
> M  +2    -0    src/plugins/platforms/drm/drm_gpu.cpp
> M  +17   -8    src/plugins/platforms/drm/drm_object_connector.cpp
> M  +2    -0    src/plugins/platforms/drm/drm_object_connector.h
> M  +48   -13   src/plugins/platforms/drm/drm_output.cpp
> M  +6    -3    src/plugins/platforms/drm/drm_output.h
> M  +1    -1    src/plugins/platforms/drm/drm_pipeline.cpp
> M  +3    -4    src/plugins/platforms/drm/drm_virtual_output.cpp
> M  +2    -2    src/plugins/platforms/drm/drm_virtual_output.h
> M  +1    -1    src/plugins/platforms/drm/egl_stream_backend.cpp
> M  +1    -1    src/plugins/platforms/drm/scene_qpainter_drm_backend.cpp
> M  +1    -1    src/plugins/platforms/wayland/egl_wayland_backend.cpp
> M  +6    -6    src/wayland_server.cpp
> M  +2    -3    src/wayland_server.h
> D  +0    -139  src/waylandoutputdevice.cpp
> A  +152  -0    src/waylandoutputdevicev2.cpp     [License: GPL(v2.0+)]
> R  +7    -3    src/waylandoutputdevicev2.h [from: src/waylandoutputdevice.h
> - 074% similarity]
> 
> https://invent.kde.org/plasma/kwin/commit/
> 0a2c511489cf4cfa7216b3222cee0430ef9a829c

This should fix the issue, it will be part of plasma 5.23.

The bug is still not fixed for X11:
https://invent.kde.org/plasma/libkscreen/-/merge_requests/35

Not fixed for me in a wayland session:
- Kubuntu 21.10 backports
- Plasma 5.24.1
- Frameworks 5.91
- Qt 5.15.2
- tested in a virtualbox v6.1.32 VM

Workaround: disable the kscreen2 service (System Settings > Startup and Shutdown > Background Services), logout, login
(re-enabling kscreen2 service directly resizes the VM window to 800x600, X session is not affected for me).

In which Plasma version should this be / or was this fixed for wayland?