Initial support for DRM async page flip

[PolyMeilex]

This allows users to select if frame should be presented with VSync or fully ASync.

blocked by: Smithay/drm-rs#190 (awaiting releasse)
blocked by: Smithay/gbm.rs#40
related: #1325

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 0% with 20 lines in your changes are missing coverage. Please review.

Project coverage is 21.23%. Comparing base (91e61f1) to head (a7e1c32).
Report is 16 commits behind head on master.

Files	Patch %	Lines
src/backend/renderer/element/mod.rs	0.00%	15 Missing ⚠️
src/backend/renderer/element/surface.rs	0.00%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1335      +/-   ##
==========================================
- Coverage   21.32%   21.23%   -0.09%     
==========================================
  Files         156      156              
  Lines       25121    25042      -79     
==========================================
- Hits         5356     5317      -39     
+ Misses      19765    19725      -40     

Flag	Coverage Δ
wlcs-buffer	18.37% <0.00%> (-0.05%)	⬇️
wlcs-core	18.03% <0.00%> (-0.07%)	⬇️
wlcs-output	7.78% <0.00%> (+0.02%)	⬆️
wlcs-pointer-input	20.05% <0.00%> (-0.13%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[PolyMeilex]

Well I'm no Smithay maintainer but still curious whether this will help with integrating tearing-control-v1 or not? Because it seems quite promising!

It actually does.

Yep, it's more or less the only use-case for this.

[PolyMeilex]

Ok, I belive this is ready.

Although I still can't test the atomic path, even tho my driver started to report AtomicASyncPageFlip as supported recently, any attempt to page flip results in Invalid argument (os error 22) (perhaps it's a code issue so any testing with presentation mode flipped to Async would be welcome, just flip VSync to Async in anvil's udev.rs)

Running with SMITHAY_USE_LEGACY=1 on the other hand works flawlesly for me already (if one can use flawless to describe tearing 😄).

[YaLTeR]

This is waiting on the tearing control PR?

[PolyMeilex]

Yep, or the other way around, I don't care. Although the protocol PR is probably more merge ready. We could also just merge the PRs into one.

[cmeissl]

Okay, so this is not going to work this way unfortunately. Async page flips have some special limitations we need to account for. For an async page flip to succeed the atomic commit is only allowed to change the framebuffer on the primary plane. Every other change will result in the page flip request to be declined.

This unfortunately also includes IN_FENCE_FD required for explicit sync. But this is something that is being worked on, so imo we should not special case this and just wait for it to land. Currently we do not support explicit sync for direct scan-out anyway.

Not sure what to do about FB_DAMAGE_CLIPS, need to check what the plan for this is. (worst case is we disable it for async page flips).

There are also driver specific limitations like for example intel not supporting async page flips if the plane uses some compressed tiling format.

So imo the most sane way to handle this is to do best guessing in render_frame if an async page flip might work.
Then in queue_frame do trail and error with a retry without async flip and remember that it failed for this frame state.
render_frame would then use the state as a feedback loop to prevent endless retries. The failed state should reset in case the format or other stuff changes allowing to re-test.

I prototyped some parts of this and will post a patch when its ready.

[cmeissl]

Okay, I put something together that should work (at least it seems to work on my system).
https://github.com/cmeissl/smithay/commits/drm_async_page_flip/ (@PolyMeilex PR branch rebased on top of current master + some small fixes)

Curious if this also works on AMD and Nvidia now @PolyMeilex @YaLTeR @Drakulix
Filtering for linear formats is probably not going to work on Nvidia and probably also not needed.
Intel also does support async page flips with some modifiers (probably only compressed one are not supported, which kind of makes sense), but I was too lazy to put together a list of working formats.

[PolyMeilex]

@cmeissl Atomic backend now works on my AMD systems, looks promising.

Rebased on master, and cherrypicked the cmeissl's commit (with some minnor reverts of debug code edits)

[PolyMeilex]

Confits resolved, everything seems to still work as expected on my AMD machines both with atomic and legacy

[Drakulix]

Feedback from the display next hackfest:

• IN_FENCE_FD will be added as a supported property in some future kernel
• FB_DAMAGE_CLIPS is unclear, but amd/intel are aware that their current set of properties is too restrictive
• There was a proposal to have an additional IN_FORMATS_ASYNC (or similarly named) property to solve the format issue.
• Other compositors currently seem to just fall back to non-tearing presentation, when the format doesn't work out or default to the legacy api. Just using linear was deemed to potentially have performance issues...

[cmeissl]

I will try to find some time in the next two weeks to go over the PR

@PolyMeilex are you fine with me updating the PR?

[PolyMeilex]

@PolyMeilex are you fine with me updating the PR?

For sure, go ahead

[nferhat]

Not to be that guy, but it's 2026 already. Gamers demand answers from the Niri gods. Will you bestow upon us the godly feature of tearing so we may dominate COD lobbies once more?

On a more serious note, what's missing as of now? What needs to be changed here or in the codebase so I could contribute? I know Rust and I want this feature badly enough to drop everything I do right now and try working on it.

• Implement wayland side of tearing control #1325 To implement the protocol that lets clients choose for themselves if they want to have tearing presentation or not
• Rebasing this branch onto main again (smithay moves really quickly, and as a side effect of this leaving some fork/branch for a little could make it a hellish nightmare to rebase)
• Free time for smithay maintainers and compositors devs to write implementation in their respective compositors, test it, make sure there's nothing wrong, test it even more, point out flaws

And after that, if it doesn't require multiple rounds of such review, then it can potentially get merged. We all want lower latency in our games, me included, and I am avid to implement this and make use of it, but having a solid implementation backing it more important.

[PolyMeilex]

Ok, it took a bit of patience, but I managed to rebase this.
The anvil implementation did not survive the rebase tho, I did a minimal reimpl instead.

It's still possible to test this by editing this line:

smithay/src/backend/renderer/element/surface.rs

Line 432 in 7ea3f73

Some(PresentationMode::VSync)

It's also worth noting that I still don't have a full grasp of what's going on in the Cmeissl's commit that made the atomic backend work, that's why I'm keeping it as a separate WIP commit.

Open question: Would dropping the seemingly more problematic atomic backend implementation and merging just the legacy impl make sense? Just to get things rolling, or should I rather just focus on trying to grasp what's needed for less hacky atomic impl?

[cmeissl]

Ok, it took a bit of patience, but I managed to rebase this. The anvil implementation did not survive the rebase tho.

It's still possible to test this by editing this line in anvil: https://github.com/PolyMeilex/smithay/blob/1072da79b699cbfb18ceac51541f847a4d907114/anvil/src/udev.rs#L1674 I will try to bring back RenderElement based presentation mode selection to Anvill soon'ish.

It's also worth noting that I still don't have a full grasp of what's going on in the Cmeissl's commit that made the atomic backend work, that's why I'm keeping it as a separate WIP commit.

Open question: Would dropping the seemingly more problematic atomic backend implementation and merging just the legacy impl make sense? Just to get things rolling, or should I rather just focus on trying to grasp what's needed for less hacky atomic impl?

Thanks again for taking the time to get this forward. imo it does not make sense without the atomic backend. Also some of the things of my commit should not longer be required as some of the limitations have been lifted in the kernel. But I need some time to look into this again :(

[PolyMeilex]

Also some of the things of my commit should not longer be required as some of the limitations have been lifted in the kernel. But I need some time to look into this again :(

The one thing I noticed is that your Linear format filters did not survive the rebase, but the impl still seems to work fine, so perhaps that's one of the limitations lifted?

[cmeissl]

Also some of the things of my commit should not longer be required as some of the limitations have been lifted in the kernel. But I need some time to look into this again :(

The one thing I noticed is that your Linear format filters did not survive the rebase, but the impl still seems to work fine, so perhaps that's one of the limitations lifted?

Possible, I don't remember all details. But one thing that should be lifted is the IN_FENCE_FD iirc.