Skip resize + chromium restart when display already matches

[masnwilliams]

Summary

VM-side companion to the API-side short-circuit. Both PatchDisplay and the multipart ChromiumConfigure (when display is the only thing in the request) currently proceed through the full xrandr/xvfb resize plus a chromium restart even when the requested width/height/refresh-rate already match the current display state. This change detects the no-op and returns success immediately — skipping the idle check, recording stop, resize, and restart.

Sister PR on the API side: kernel/kernel#2233 (skips the configure call entirely when the request matches the pool image default). This PR catches the same case from the VM side, plus any caller that passes a non-default-but-already-current viewport.

Changes

• Extract resolveDisplayParams so PatchDisplay and chromiumPrepareDisplay share one definition of "the request changes nothing."
• PatchDisplay returns 200 immediately when changed == false.
• chromiumPrepareDisplay returns a nil plan, which the caller already handles as skip-apply.

Test plan

• go test ./cmd/api/api/ — new TestResolveDisplayParams covers matching dims with and without refresh-rate, mismatched width, refresh-rate-only mismatch, partial body, and nil body
• Manual: deploy to a metro, send PatchDisplay {width:1920,height:1080} to an instance launched at 1920x1080, confirm no chromium restart in supervisor logs and no xrandr/xvfb activity

---

Note

Medium Risk
Changes core display resize and Chromium configure paths; incorrect sticky refresh-rate state could misclassify real resizes as no-ops, but scope is limited to idempotent display updates.

Overview
PatchDisplay and ChromiumConfigure display prep now treat “already at requested width/height/refresh rate” as a no-op: shared resolveDisplayParams merges the body with current state and sets changed. When nothing would change, PatchDisplay returns 200 immediately (skipping idle checks, recording stop, Xvfb/xrandr/CDP resize, and Chromium restart); chromiumPrepareDisplay returns a nil plan so the configure flow skips display apply.

On headless (Xvfb), xrandr often does not report refresh rate, so the VM adds lastHeadlessRefreshRate (updated on viewport override and after Xvfb resize) and getCurrentResolution falls back to that sticky value when the rate was not parsed—so repeat configure calls with the same non-default rate are recognized as no-ops, not mistaken for a change from the default 60 Hz.

Tests cover resolveDisplayParams cases and sticky refresh-rate behavior.

^{Reviewed by Cursor Bugbot for commit b35386a. Bugbot is set up for automated code reviews on this repo. Configure here.}

[firetiger-agent]

Firetiger deploy monitoring skipped

This PR didn't match the auto-monitor filter configured on your GitHub connection:

Any PR that changes the kernel API. Monitor changes to API endpoints (packages/api/cmd/api/) and Temporal workflows (packages/api/lib/temporal) in the kernel repo

Reason: PR modifies VM-side display handling logic, not kernel API endpoints (packages/api/cmd/api/) or Temporal workflows (packages/api/lib/temporal); the companion API-side changes mentioned are in a separate PR.

To monitor this PR anyway, reply with @firetiger monitor this.

[rgarcia]

requesting changes for one behavior gap:

• server/cmd/api/api/display.go:198 — the no-op check includes refreshRate, but the headless/Xvfb path does not appear to persist or later recover the requested refresh rate. setViewportOverride stores it temporarily, but backgroundResizeXvfb clears that override once width/height match, and getCurrentResolutionFromXrandr falls back to 60 when xrandr output has no _rate suffix. so a headless request like 1280x720@25 can be applied, then after the background resize clears the override, the next identical request sees current as 1280x720@60 and is not treated as a no-op. this undercuts the “all three values equal” behavior for non-60 refresh rates on headless.

suggested fix: either persist the last requested refresh rate for Xvfb after the background resize, or normalize headless refresh semantics explicitly so the no-op comparison uses the same canonical value that future calls will observe.

[hiroTamada]

Actually, would it be easier to talk to x-org and xfvb to get the current resolution rather than persisting viewport state in memory?