The headless window failure is sRGB, not GLX — making it optional would let CI run the Verify: M UI scripts

[ErwanLegrand]

Split out of #19. That issue is about Wayland and is not fixable in this repository — baseview has no Wayland backend at 0.2 or 0.3, and the pin is forced rather than conservative (published egui-baseview 0.6.0 requires baseview 0.2.2). This issue is the part that is fixable here, and it is worth more than it looks.

The mechanism is misattributed in #19

#19's body says GLX. It is sRGB. crates/namir-ui/src/app.rs builds its window as:

let settings = egui_baseview::EguiWindowSettings { title, size, ..Default::default() };

so GlConfig::srgb stays true, and glXChooseFBConfig then matches none of Xvfb's 320 available configs. The window never opens under a headless X server, and the failure reads as a GLX problem because that is the call that returns nothing.

(#19's own comment already suspected this; the body was never corrected. Its closing claim that the UI manual scripts were never executed is also stale — fr-ui-020 and fr-ui-070 were run by a human at M9b, 1621caf / 9e712d3.)

Why this is worth doing

Six Verify: M Musts currently record no pass, and five of them are UI scripts that need a human at a screen: FR-UI-030, FR-UI-040, FR-UI-050, FR-UI-070, plus FR-IN-020's display half, which has no manual document at all (it went uncovered when the traceability gate learned to read compound Verify: methods, #27).

If the window can open headless, those scripts become runnable in CI instead of by hand. That does not automatically make them Verify: M artifacts — D-18.6 still governs what a manual document can stand for — but it converts "needs someone at a machine" into "runs on every push", which is the actual reason those six have sat unexecuted.

Suggested shape

Make sRGB optional in open_blocking / open_parented: attempt the default config, and on failure retry with srgb: false. Both call sites are in crates/namir-ui/src/app.rs. A headless runner gets a window; a real machine is unaffected because the first attempt succeeds.

Worth confirming the fallback does not change rendered colour on a real display before relying on it for a screenshot-comparing test — an sRGB-less framebuffer will differ, which matters if any script asserts on appearance rather than on structure.

[ErwanLegrand]

Partial — the mechanism fix landed and is CI-gated; the payoff this issue is actually about has not. Leaving open.

Landed. open_with_srgb_fallback (crates/namir-ui/src/app.rs:357) attempts the default config and, on failure, retries with gl_config.srgb = false (:370); both open_blocking (:431) and open_parented (:461) go through it — c45f2d2. The mechanism is written up at :319-332, and it agrees with your diagnosis: GLX is healthy under Xvfb on Mesa 25.2.8/llvmpipe, none of its 320 FBConfigs carries the sRGB flag, and GLX is merely the call that comes back empty. Tests at :1144-1221 pin that the default asks for sRGB, that a failed open is retried exactly once without it, and that a successful first attempt is not retried.

A required (not continue-on-error) headless-window job was added — .github/workflows/ci.yml:314-356, dde8488 — running manual_window_smoke under xvfb-run -a with libgl1-mesa-dri. Review found its first form asserted only the example's exit status, which baseview's X11 open_blocking makes meaningless: it joins the window thread with unwrap_or_else(eprintln!), so a render that panicked on every frame would still exit 0. 58027e0 gave it teeth — the example counts rendered frames and exits 1 unless it drew all of them, and the step greps for that line with the count read out of the example's own FRAMES_BEFORE_CLOSE rather than hard-coded. Note the job has only been run under local Xvfb, not yet on a GitHub-hosted runner.

Not landed: the reason the issue exists. docs/manual-tests/fr-ui-030-accessibility-script.md, fr-ui-040-numeric-value-entry.md and fr-ui-050-reset-and-fine-adjust.md all still read NOT EXECUTED on trunk, and FR-IN-020's display half still has no manual document. Nothing yet drives those scripts under the now-openable headless window; only the smoke example runs there.

On the premise. This issue's own title is right, and app.rs now names #19's original diagnosis as the misattribution it was. The stale GLX prose is not corrected everywhere, though: docs/manual-tests/fr-ui-110-brand-mark.md:59 still reads "baseview 0.2.2's X11 path needs a GLX-capable display and Xvfb provides none", and #19's body still carries the same clause. docs/02-architecture.md's R-16 and roadmap §12/M9b already correct it in place, so those two are the residue.

---

Generated by Claude Code