[kwin] [Bug 524346] Composited tearing requests fall back to VSync

[email protected] (Unknown)
Newsgroups gmane.comp.kde.devel.bugs
Message-ID <[email protected]/>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.