fix: reapply VRR on physical monitor reconnect#1200
Open
rockerBOO wants to merge 1 commit into
Open
Conversation
Physical DRM hotplug never emits wlr_output.events.request_state (only the X11/Wayland nested backends do), so the existing requestmonstate rule-reapply path was dead code for real monitors. On reconnect, createmon does the initial modeset while the connector is still settling, so the adaptive-sync enable test fails and VRR comes back disabled. Recover VRR through two paths: - Add a per-monitor retry timer (monitor_vrr_retry_callback), armed by createmon when the rule wants VRR but the initial enable test failed. It re-tests and commits every 200ms (up to 25 attempts) until the connector accepts adaptive sync, covering the case where the monitor reconnects with no focused client. - Rebuild updatemons' output-manager snapshot after focusclient so state changed by check_vrr_enable (VRR enabled) is pushed to clients like wlr-randr instead of the stale pre-focus snapshot. check_vrr_enable now also checks each commit result and rolls back is_vrr_enabling on failure so a later attempt can retry. Remove the dead requestmonstate rule-reapply block. Recovery drops from ~25s to ~125ms (windowed) / ~200ms (empty) after modeset.
Collaborator
|
why not wlr-randr --output eDP-1 --on --adaptive-sync enabled use this? |
Author
|
Every time I turn my monitor on again I would need to re-run the wlr-randr command to enable it. We already are setting the VRR in our Mango config so makes it more consistent than to silently drop VRR when the monitor power refreshes. I had a udev command to detect the monitor coming on and running wlr-randr but it seemed like a workaround to getting Mango to re-enable VRR. Edit: Also could remove the "retry" parts as it will try to apply the VRR when the cursor enters the screen so that trade off is probably fine. |
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.
The monitor VRR was not getting set after turning off and turning on the monitor.
The VRR attempts to apply when the monitor is focused. There is a retry mechanism to attempt to set it in a loop to let the monitor settle.
The following code is to handle when the output commit fails it will remain in "enabling" mode. But this pattern is kinda sloppy though and duplicated a few times.
This issue is likely similarly happening for HDR but that has a larger number of changes and harder to check because tooling doesn't support checking HDR support quite yet. I have a branch of
wlr-randrto support looking at HDR support and a monitor that supports HDR so I can look into this if an approach here is acceptable.Willing to make changes and feedback if the HDR changes would be desired.