Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix stuck-frame-after-mode-switch bug #3673

Merged
merged 3 commits into from
Nov 19, 2024
Merged

Fix stuck-frame-after-mode-switch bug #3673

merged 3 commits into from
Nov 19, 2024

Conversation

RAOF
Copy link
Contributor

@RAOF RAOF commented Nov 18, 2024

No description provided.

When we perform a mode switch Mir first tears down all the `Compositor`s,
does the switch, and then creates a new set of `Compositor`s, one for each
output.

But, in the buffer queue code, we track which `Compositor`s have accessed
the “current” buffer of a surface, and only advance to the most recently
submitted buffer when the `Compositor` had already seen the current one.

After the mode switch, *all* the `Compositor`s are new, so *none* of them
will have seen the “current” buffer, and so will not receive the most
recently submitted client buffer until something else triggers a new
composite pass.

The buffer queue code is going to need to change significantly in the
forseeable future to accomodate the requirements of some Wayland extensions,
so work around this problem by having each `Compositor` thread mark
itself as a user of the “current” buffer on construction, so the
first composition pass will receive the most recent buffer.
@RAOF RAOF requested a review from a team as a code owner November 18, 2024 06:44
Copy link
Contributor

@tarek-y-ismail tarek-y-ismail left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code and new docs look good. @Saviq does this fix the issue on your end?

Edit: Tried to see if I can test on my set up using the built-in display. Mir is convinced it only supports 1920x1080@144 Hz :/

Copy link
Collaborator

@Saviq Saviq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixes the issue I saw (display stuck after refresh rate changes until the compositor redraws).

@Saviq Saviq added this pull request to the merge queue Nov 19, 2024
Merged via the queue into main with commit e72bacc Nov 19, 2024
24 of 28 checks passed
@Saviq Saviq deleted the fix-multi-monitor-arbiter branch November 19, 2024 11:13
@AlanGriffiths AlanGriffiths mentioned this pull request Nov 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants