Please attach the output of drm_info for before adding the second output, for when it's added, and for when it's removed again

Created attachment 164144 [details]
Immediately after login (before adding screen) ...

Created attachment 164145 [details]
After adding screen

Created attachment 164146 [details]
After removing screen

drm_info output attached as requested; running system was Fedora Rawhide (40), fresh up-to-date + COPR KDE Plasma 6 beta 1.

I also have a local build environment (with some fixes) where I can see the same behaviour from logs.

From the implementation, I cannot tell how the framebuffer(?) backing the ouput(?) ever gets removed.

Basically, as part of the change sequence, the second screen goes into !isConnected with resolution 1280x800, and the current implementation still tries to talk to "it" (connector/output). This fails on various DRM calls:
```
Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: Connection on "Virtual-2-unknown" is in state 2 ?libkwin.so.6?|?libkwin.so.6?|KWin::DrmBackend::updateOutputs|KWin::DrmBackend::handleUdevEvent|?libQt6Core.so.6?
Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: updateProperties: mode change detected on "Virtual-2-unknown" for mode index 0 towards 1280 800 ?libkwin.so.6?|?libkwin.so.6?|KWin::DrmBackend::updateOutputs|KWin::DrmBackend::handleUdevEvent|?libQt6Core.so.6?
Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: updateProperties: modes equal is false ?libkwin.so.6?|?libkwin.so.6?|KWin::DrmBackend::updateOutputs|KWin::DrmBackend::handleUdevEvent|?libQt6Core.so.6?
Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: DrmPipeline::legacyModeset ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?
Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: DrmLegacyCommit::doModeset on "/dev/dri/card0" "Virtual-1" connected true ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?
Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: Failed to set legacy property: Invalid argument ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?
Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: Setting legacy dpms failed! Invalid argument ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?
Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: DrmPipeline::legacyModeset ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?
Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: DrmLegacyCommit::doModeset on "/dev/dri/card0" "Virtual-1" connected true ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?
Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: DrmPipeline::legacyModeset ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?
Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: DrmLegacyCommit::doModeset on "/dev/dri/card0" "Virtual-2" connected false ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?
Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: drmModeSetCrtc failed: Invalid argument ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?
```

There are two ways to get a virtual screen removed

a) the way described earlier - basically this retains the configuration of the primary screen
b) un-maximizing the whole setup, which cause VMware Workstation to collapse everything into a "simple window", causing the primary screen to also resize

In the case of a), the second virtual screen does not disappear (as described below). In the case of b), the second virtual screen _does_ in fact disappear. That's a bit of an odd situation, to be honest.

I suspect that to have b) working my hack from https://bugs.kde.org/show_bug.cgi?id=477985 needs to be in place, otherwise the resize on the primary screen will not end up well.

Tested the "cycle multiple monitors" feature of VMware Workstation on Fedora Workstation Rawhide F40 - it works there.

The root cause of this defect is a design challenge in the atomic commit code.

Whenever an output is changed ("DrmGpu::updateOutputs"), among other things, the 1:1 matched up internal processing pipeline of kwin gets "managed", too. The GPU _instance_ retains a list of those pipelines in m_pipelines. When a new pipeline is added, it is added immediately to m_pipelines. When a pipeline is removed, it is immediately removed from m_pipelines.

After the GPU instance state for pipelines has been altered, all this gets tested and ends up in DrmGpu::testPipelines(). This then does commitPipelines(m_pipelines, DrmPipeline::CommitMode::TestAllowModeset. This will pass, and all is good - new configuration is accepted.

Alas, what is missing is a successful atomic commit to clean up any _removed_ pipeline(s) all the way into the _kernel_. This has the effect that the _DRM plane_ that was connected to the removed pipeline still has a framebuffer object attached to it that is now frozen in time, because nothing ever updates it. And because there is still that framebuffer object around, the VMware Workstation host will faithfully show that forever.

This behaviour is best illustrated by adding one single log statement to the implementation:

```
  DrmPipeline::Error DrmPipeline::commitPipelinesAtomic(const QList<DrmPipeline *> &pipelines, CommitMode mode, const QList<DrmObject *> &unusedObjects)
{
+      qCDebug(KWIN_DRM) << "commitPipelinesAtomic is applied to" << pipelines.size() << "pipelines";
```

Notice how this will print the number(a) as explained above - numbers that are not good ;). Also inspect the output of drm_info gathered in attachement "After removing screen" and notice how plane 2 (which is the removed screen) still has a non-zero framebuffer buffer ID (FB_ID) value (96)

As far as I can see, this defect only hits systems where an output does not _physically_ disappear. Or, in other words, if you plug the cable, well, there is nothing coming down that wire any more, right?

So, this will most likely only detrimentally _affect_ systems with non-physical screens which allow multi-screen configurations. Such as (confirmed) VMware Workstation (and most likely all desktop hypervisor products created by VMware, for instance VMware Fusion). Perhaps GNOME Boxes / qemu / kvm (with virtio-gpu)? Perhaps VirtualBox? Perhaps whatever is using the qxl driver? Whatever does virtualization and software abstraction tricks.

It will also only _affect_ users of said systems who turn on and _off_ one more screens in addition to the primary screen.

So while the defect is universal, after triage, its impact (most likely) is rather limited.

Interesting, I wonder if the issue would affect KVM users as well.

No, normal drivers turn off the CRTC used on a given connector when the connector goes away. The VM drivers should imo do the same, but as it's probably unspecified (like with all drm things), we should probably work around it.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4822

Git commit 9ea6f311ead4566feb4d94db23a815230302e5c9 by Xaver Hugl.
Committed on 16/02/2024 at 11:20.
Pushed by zamundaaa into branch 'master'.

backends/drm: force a modeset when connectors are unplugged

And turn off unused CRTCs with legacy

M  +6    -6    src/backends/drm/drm_gpu.cpp
M  +1    -0    src/backends/drm/drm_gpu.h
M  +1    -1    src/backends/drm/drm_pipeline.cpp
M  +1    -1    src/backends/drm/drm_pipeline.h
M  +6    -1    src/backends/drm/drm_pipeline_legacy.cpp

https://invent.kde.org/plasma/kwin/-/commit/9ea6f311ead4566feb4d94db23a815230302e5c9

Git commit c84739d51e97356d38778ff143d181ae14462877 by Xaver Hugl.
Committed on 16/02/2024 at 11:41.
Pushed by zamundaaa into branch 'Plasma/6.0'.

backends/drm: force a modeset when connectors are unplugged

And turn off unused CRTCs with legacy


(cherry picked from commit 9ea6f311ead4566feb4d94db23a815230302e5c9)

M  +6    -6    src/backends/drm/drm_gpu.cpp
M  +1    -0    src/backends/drm/drm_gpu.h
M  +1    -1    src/backends/drm/drm_pipeline.cpp
M  +1    -1    src/backends/drm/drm_pipeline.h
M  +6    -1    src/backends/drm/drm_pipeline_legacy.cpp

https://invent.kde.org/plasma/kwin/-/commit/c84739d51e97356d38778ff143d181ae14462877