Sylpheed/docs/re/f1-hold-capture-harness-debugged.md

F1 dynamic attempt — harness debugged through four bugs, no measurement yet

Status: ❔ not answered. Built tools/re-capture/f1_hold_capture.py to close out issue #1 with an actual draw-log measurement — boot to the settled main menu (the proven glyph-gated route), arm the F10 UI-draw capture, hold a direction, read the cursor's position per frame. Never completed a clean end-to-end run this iteration; four real bugs found along the way, three fixed and confirmed, one fixed but not re-verified. Same shape as f1-menu-repeat-harness-built-not-answered.md — the harness is closer, the number still isn't here.

⚠️ Container reset warning, read this if you are a fresh session: bug 3 below will hit any scripted run-canary invocation in a container that has never signed in a profile — which is every container right after a restart, per this project's own "your session is new each time" note. boot_menu.sh already handles it; a bare run-canary call does not.

Bug 1 — tap() shelled out to pad.py with the wrong environment

First attempt's "tap A" used subprocess.run([sys.executable, PAD, ...]) without passing this script's own env dict, so the subprocess inherited os.environ instead — where XENIA_PAD_FILE was never set at the OS level, only in the local dict. pad.py wrote its default /tmp/xenia_pad.txt; Canary was watching OUT/pad.txt. The press never arrived: an unobserved press that looks identical to a dead pad, and it cost one full 520 s boot before the mismatch was found (only one [file-pad] log line the whole run — the initial clear).

Fixed: an in-process tap() using the same pad() function the hold uses, no subprocess. Confirmed working the very next run: title reached at 154.5 s, tap delivered, menu reached at 163.0 s.

Bug 2 — the persisted ui_draw_capture_frames was 3, disc-wide default

ui_draw_capture_frames = 3 / ui_draw_capture_max = 20000 sat in ~/.local/share/Xenia/xenia-canary.config.toml from a previous session — an old capture's window, kept because --log_ui_draws=true (the flag most existing scripts pass) is now a documented no-op (command_processor.cc: "OBSOLETE — the UI draw-order capture is armed by F10 unconditionally now"). Passing --ui_draw_capture_frames=3000 on the command line did not visibly change the value logged at startup, and this container's saved config wins for these two cvars regardless of the flag.

Fixed: edited the toml directly, 600 / 400000 — wide enough to cover a multi-second hold at any plausible present rate. Confirmed applied (log dump shows the new values) on the next run, though it wasn't the run that also isolated bug 3, so it hasn't independently produced a capture yet.

Bug 3 — no signed-in profile, and it reproduces the documented crash

The real blocker. This container had no content/ directory at all — a fresh container after a restart, exactly as the loop brief warns, and f1_hold_capture.py (unlike boot_menu.sh) never checked. Without a profile, the title shows a sign-in dialog, IsUIActive() goes true, and — this is the exact crash structures/title-a-press-fault.md already diagnosed — XamInputGetKeystrokeEx returns success with an empty keystroke forever, the game's unbounded pump queues every empty result, and it eventually crashes on a bad allocation.

Reproduced, not just matched by description: the crash dump's PC (0x824578A0) sits 0x868 past sub_82457038 (that doc's "keystroke pump"), registers hold values in the 0x828F3xxx range (the input-manager singleton at 0x828F3888), and the access violation address relationship — 0x1701D0000 (host) → 0x701D0000 (guest, r9) — matches that doc's own worked arithmetic exactly. Without a profile the crash repeated in a tight loop (one dump roughly every 200 log lines) for the entire run, starting before F10 was ever pressed — this is not an F10 side effect, it is the title's own boot path with no profile to sign into.

Fixed: run-canary --create_profile_if_none=F1Probe, wait ~5 s, kill it — creates content/<XUID>/. Script now resolves that XUID and passes --logged_profile_slot_0_xuid=<XUID>, matching boot_menu.sh. Confirmed: zero crash dumps in the run that used it, against dozens per run before.

Bug 4 — no root-window blank before launch; found, not re-verified

The run after fixing bug 3 detected "TITLE" at 2.6 s — long before any real window could exist — and never recovered. skip_intro.sh's own header explains why: "The X root keeps the DEAD session's last frame, so a fresh launch would be detected as already at the title." The previous run's killed window left stale pixels on the shared :98 display; my script never blanked it, unlike every proven boot script.

Fixed in the script (xsetroot -solid black before each launch) but not re-run this iteration — four bugs and roughly nine minutes of boot time across four attempts is where this stopped rather than chasing a fifth.

What's left

The harness should now be correct: env-safe input, a wide enough capture window, a signed-in profile, a blanked root. The next run is the actual measurement — hold a direction on the settled menu, read read_draws.py's per-frame quad positions, group by (page, width, height) shape (the approach menu_repeat_probe.sh's own notes call "track one quad shape's position over time," the one that correctly reports no motion when there is none), and report which shape-group's position changes, at what frame spacing, at the achieved present rate.

Reach

Everything here is ⟨harness⟩ / ⟨environment⟩ — about this container and this tool, not about the game. Bug 3's crash mechanism is not new (already fully diagnosed in structures/title-a-press-fault.md); what's new is the trigger (a freshly-reset container with no profile) and that it reproduces byte-for-byte against that page's own addresses. No claim about F1's actual repeat rate is made or changed here.