https://bugs.kde.org/show_bug.cgi?id=524346

--- Comment #2 from [email protected] <[email protected]> ---
Further testing suggests that format selection is only part of the problem. The
async atomic commit still seems to include a non-primary plane that does not
support async flips, so the Intel driver rejects the whole commit.

This discussion looks very relevant:
[https://www.mail-archive.com/dri-devel%40lists.freedesktop.org/msg583827.html](https://www.mail-archive.com/dri-devel%40lists.freedesktop.org/msg583827.html)

The sequence described there is roughly:

1. Disable the cursor plane in a normal synchronous commit.
2. Submit an async commit that updates the primary plane, but also includes the
already-disabled cursor plane again.

The secondary plane is already off, and including it again is effectively a
no-op. However, the Intel driver still sees that plane in the atomic state,
notices that it is not capable of async flips, and rejects the entire commit.

That seems to match what I am seeing here with plane 2A. If the already
disabled plane is left out of the commit, the primary-plane update can be
presented asynchronously.  I'm not sure what's the best thing to do here would
be for KWin, however locally I changed the code here
https://invent.kde.org/plasma/kwin/-/blob/v6.6.6/src/backends/drm/drm_pipeline.cpp?ref_type=tags#L230
to simply avoid the redundant plane update, with something like this:

```
// hasPendingCommit added in `drm_commit_thread.h`
const bool alreadyDisabled = !plane->currentBuffer() &&
!m_commitThread->hasPendingCommitFor(plane);
if (commit->isTearing() && layer->type() != OutputLayerType::Primary &&
alreadyDisabled) {
    return Error::None;
}
plane->disable(commit);
return Error:None;
```

This restores tearing as desire on my machine. So I think there are two
independent behaviours here that prevent tearing of composited surfaces.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to