Respect disable-direct-scanout in DMA-BUF feedback#3913
Open
ewgdg wants to merge 1 commit into
Open
Conversation
0060b92 to
38167d3
Compare
38167d3 to
159e1e3
Compare
159e1e3 to
7c22450
Compare
disable-direct-scanout in DMA-BUF feedback
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
debug { disable-direct-scanout }should disable scanout path consistently, not only final direct-scanout attempt.When direct scanout is disabled, advertising scanout-preferred DMA-BUF tranches no longer provides the intended benefit, but can still make clients choose scanout-oriented allocations.
This also intentionally keeps the regular render feedback render-only, even when the output is on the primary render node. Previously, in that case, niri reused the scanout feedback as the render feedback:
That made the default/render path contain scanout tranches too on the primary render node. As a result, Smithay's
select_dmabuf_feedback()could not meaningfully choose between render feedback and scanout feedback, because both choices advertised scanout-oriented allocations.This makes scanout feedback less aggressive in general: composited surfaces keep render-oriented feedback, while Smithay can still advertise scanout feedback for surfaces that are actually zero-copy candidates or failed scanout due to buffer properties.