Repository navigation
[Ubuntu] Fix fenced Present freezes without disabling asynchronous rendering - #3
Merged
Merged
Conversation
A fence notification is one-shot, but re_execute() can leave the Present request alive while it waits for its target MSC. Clear the callback before re-entering the execution path. If that path must wait again, it installs a new callback itself. This is required when the Sync trigger walker restarts after a callback: otherwise a still-live request can be called repeatedly in the same scan. It also prevents a later trigger of a reused fence from executing the old request again. The same callback-lifetime correction is used by Termux:X11: KiralyCraft/termux-x11@fc534e5 (cherry picked from commit cdc4869f26c739e4202169b332f2e3e3117f4571)
After a COPY Present, Idle permits the client to reuse the source pixmap and reset its wait fence for a later frame. The old request may still be queued for its delayed Complete notification. Re-executing that request must not wait for the source again, because that now belongs to a different presentation. Waiting a second time can overwrite blocking_event with the old copied request. That request subsequently completes without draining blocked_queue, leaving newer requests blocked indefinitely. Only perform acquisition before the copy. The first wait, asynchronous render fences, and delayed completion scheduling are unchanged. (cherry picked from commit a0d3e8912ece5e8435c456a56c4d48d75de3346f)
lfdevs
force-pushed
the
dev/ubuntu/present-fence-lifetime
branch
from
October 8, 2026 15:34
16692d7 to
588b1be
Compare
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
2 participants
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.
Variant of PR #2 for Ubuntu 26.04.
present: disarm the wait-fence callback before re-execution
A fence notification is one-shot, but re_execute() can leave the Present request alive while it waits for its target MSC. Clear the callback before re-entering the execution path. If that path must wait again, it installs a new callback itself.
This is required when the Sync trigger walker restarts after a callback: otherwise a still-live request can be called repeatedly in the same scan. It also prevents a later trigger of a reused fence from executing the old request again.
The same callback-lifetime correction is used by Termux:X11: KiralyCraft/termux-x11@fc534e5
(cherry picked from commit 3578597)
xwayland: do not reacquire a copied Present pixmap
After a COPY Present, Idle permits the client to reuse the source pixmap and reset its wait fence for a later frame. The old request may still be queued for its delayed Complete notification. Re-executing that request must not wait for the source again, because that now belongs to a different presentation.
Waiting a second time can overwrite blocking_event with the old copied request. That request subsequently completes without draining blocked_queue, leaving newer requests blocked indefinitely.
Only perform acquisition before the copy. The first wait, asynchronous render fences, and delayed completion scheduling are unchanged.
(cherry picked from commit 99f0115)