display: converge X root on the configure stop/start resize path#312
Open
Sayan- wants to merge 1 commit into
Open
display: converge X root on the configure stop/start resize path#312Sayan- wants to merge 1 commit into
Sayan- wants to merge 1 commit into
Conversation
The batched chromium-configure stop/start path applied the Neko screen reconfig with a bare setResolutionViaNeko and trusted the RPC return, unlike the live-resize path (PatchDisplay), which polls the X root and retries the reconfig when it does not converge. Neko applies screen configuration asynchronously and can silently drop a reconfig that lands while a previous one is still in flight, leaving the X root at the dummy DDX default (3840x2160). When that happens on the configure path, Chromium is then restarted in --kiosk and maximizes onto the stale root, so the live view renders the browser in a small corner of the streamed frame. It is intermittent because it only manifests when the reconfig is dropped, and the bare RPC returns success without confirming it took effect. Extract the apply-poll-retry loop into applyResolutionAndConverge and route both PatchDisplay and the configure stop/start path through it, so the two resize paths share one convergence guarantee instead of the guard living on only one of them (which is how this regression arose).
Sayan-
force-pushed
the
hypeship/configure-display-converge
branch
from
4a3a4e1 to
89b7801
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
1 participant
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.
Problem
On the batched chromium-configure stop/start path (
chromiumDisplayApplyWhileStopped), the Neko screen resize was fire-and-forget: it calledsetResolutionViaNekoand returned as soon as Neko ACKed, without waiting for the X root to actually reach the requested size. Neko applies screen config asynchronously and can silently drop a reconfig that lands while a previous one is in flight, leaving the root at the dummy DDX default (3840x2160). Chromium then relaunches in--kioskand maximizes onto the stale root, so the live view shows the browser in a small corner of the frame. Intermittent, and the call returns 200 despite the wrong size.This branch runs whenever a profile/extension/policy/flags change is bundled with a viewport change in the same configure call. The live-resize path (
PatchDisplay) already guards against this (poll + retry, #280); the stop/start branch never got that guard.Fix
Extract the apply-poll-retry loop into
applyResolutionAndConvergeand route both paths through it, so the convergence guarantee can't drift between them again.PatchDisplaybehavior is unchanged; the stop/start path now waits for the resize to take effect before Chromium relaunches.Testing
go build,go vet,go test ./cmd/api/api/,gofmtall clean. No unit test (helper needs live X/Neko; matches the untested #280 loop). Live repro not achieved — the race is timing-sensitive and low-probability — but the mechanism is confirmed in code and in prod logs (frequentrealized=3840x2160drops, recovered on the guarded path).