wayland/compositor: add schedule_barrier handler for commit timing

[skygrango]

When the surface has pending transaction, at least one blocker may be in a pending or cancelled state, preventing the commit from proceeding.

This PR adds a CompositorHandler::schedule_barrier hook to notify the compositor when there are no ready transactions, allowing it to inspect and release the corresponding barrier state.

I’ve tried various approaches, but I couldn’t get commit-timing-v1 to work correctly with the existing Smithay. The main issue was the lack of a proper point in time to handle blockers.

I implemented commit-timing on top of this approach, and it is currently working well in my tests. I’d like to propose this approach as a basis for implementing commit-timing. There may be better approaches, but I think this could be a reasonable short-term solution.

Description

Checklist

• I agree to smithay's Developer Certificate of Origin.

[cmeissl]

I am not against this in general, but I am curious what issues you faced with the commit timing (and fifo) implementation smithay already provides?

[skygrango]

I am not against this in general, but I am curious what issues you faced with the commit timing (and fifo) implementation smithay already provides?

Thanks for taking the time to review this!

The biggest challenge I encountered when implementing commit-timing in cosmic-comp comes from its per-output threading model. Each output has its own dedicated thread, and the output thread follows an event-driven execution model.

In this sense, the architecture behaves similarly to a classic client-server model: commit() currently acts as the event source that drives the output surface thread, where scheduling and rendering decisions are made.

The problem arises when a commit() is blocked by a commit-timing blocker. Once the commit is blocked, cosmic-comp effectively loses the event source that drives the corresponding surface. As a result, the output thread has no further event to trigger the scheduling and rendering logic required to eventually process the blocked commit.

[cmeissl]

The biggest challenge I encountered when implementing commit-timing in cosmic-comp comes from its per-output threading model. Each output has its own dedicated thread, and the output thread follows an event-driven execution model.

In this sense, the architecture behaves similarly to a classic client-server model: commit() currently acts as the event source that drives the output surface thread, where scheduling and rendering decisions are made.

The problem arises when a commit() is blocked by a commit-timing blocker. Once the commit is blocked, cosmic-comp effectively loses the event source that drives the corresponding surface. As a result, the output thread has no further event to trigger the scheduling and rendering logic required to eventually process the blocked commit.

I see, thanks for explanation. When implementing commit timing I tried to provide a way to customize the commit hook to allow custom behavior. CommitTimingManagerState::unmanaged provides a way to disable the automatic pre-commit hook and CommitTimerBarrierState::next_deadline allows to retrieve the next installed deadline. So maybe a custom hook could install a calloop timer to drive the commit logic? next_deadline could be used after commit to re-arm the timer.

[skygrango]

I see, thanks for explanation. When implementing commit timing I tried to provide a way to customize the commit hook to allow custom behavior. CommitTimingManagerState::unmanaged provides a way to disable the automatic pre-commit hook and CommitTimerBarrierState::next_deadline allows to retrieve the next installed deadline. So maybe a custom hook could install a calloop timer to drive the commit logic? next_deadline could be used after commit to re-arm the timer.

I missed this! Your proposal is very helpful. Although, does this mean that we would have to check whether CommitTimerStateUserData exists in the surface tree on every commit()?

[skygrango]

Oh, I see! Using add_pre_commit_hook should work. I’ll give this approach a try.

[skygrango]

Checking CommitTimerStateUserData for each surface does indeed work. Although it isn’t precise enough, it is clearly sufficient. Thank you for your help.