https://bugs.kde.org/show_bug.cgi?id=478476
--- Comment #9 from Stefan Hoffmeister <stefan.hoffmeis...@econos.de> ---
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)
--
You are receiving this mail because:
You are watching all bug changes.
