From 6fd8cd34f27451d1f7cd68feeb721bffaa38e930 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Tue, 18 Aug 2026 22:45:08 +0000 Subject: [PATCH] =?UTF-8?q?docs/re:=20the=20scripted=20route=20to=20the=20?= =?UTF-8?q?menu=20does=20not=20work=20=E2=80=94=20measured,=20not=20assume?= =?UTF-8?q?d?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The previous entry named the next step: "tap (A) once per second and see whether the success rate goes to 1". It was run. The answer is no. 40 presses at 1/s on the title change nothing, and neither does one each of START, B, BACK, X and Y. Every press was delivered (the driver logs down/up for each) and the new [RE-INPUT] diagnostic never fired, so nothing was swallowed — the guest received them and ignored them. Also recorded, because it destroys a run rather than merely wasting it: tapping (A) through the boot (88 presses over the intro) ends on a permanent black screen with no crash and no throw. What is left is a difference in STATE, not in input: the one success came on a title that appeared ~83 s into a warm boot, the failures on titles that appeared after a full attract cycle. "The attract-loop title is a non-interactive presentation" is written down as a hypothesis with the experiment that would settle it — a log_ui_draws capture in each state, looking for ptbtn00. --- docs/re/BACKLOG.md | 12 +++++--- docs/re/canary-scripted-input-traps.md | 42 +++++++++++++++++++++++--- 2 files changed, 45 insertions(+), 9 deletions(-) diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md index 82296c63..fb87fa5c 100644 --- a/docs/re/BACKLOG.md +++ b/docs/re/BACKLOG.md @@ -171,10 +171,14 @@ available in the container. **And a second screen is NO LONGER BLOCKED, but it is not routine either.** The main menu has been reached (screenshot in [`canary-scripted-input-traps.md`](canary-scripted-input-traps.md)), so the -"Ⓐ is dead" reading is withdrawn; what remains is that Ⓐ advances the title only -intermittently — one success in about four tries, with the press verifiably -delivered each time. A reliable route to the menu is the next cheap step, and it -is what the second screen's capture needs. +"Ⓐ is dead" reading is withdrawn. But the scripted reproduction **failed**: 40 +presses at 1/s move nothing, and neither do START/B/BACK/X/Y, with every press +verifiably delivered and nothing swallowed. The single success came on a title +that appeared ~83 s into a warm boot; the failures on titles that appeared after +a full attract cycle. The reading that the attract-loop title is a +non-interactive presentation is a **hypothesis**, and the cheap test is a +`log_ui_draws` capture in each state — if the interactive one draws `ptbtn00` +and the attract one does not, that is the tell. The earlier reading, kept because it is what the evidence looked like: the title's Ⓐ leads into a content/save path that crashes the guest with diff --git a/docs/re/canary-scripted-input-traps.md b/docs/re/canary-scripted-input-traps.md index 0e2f2278..256663ac 100644 --- a/docs/re/canary-scripted-input-traps.md +++ b/docs/re/canary-scripted-input-traps.md @@ -109,10 +109,42 @@ and the window has not been pinned down. looked like hard evidence for the `IsUIActive` theory and means nothing. The theory had to be tested with a real log line instead. +## The scripted reproduction was tried, and it failed + +"Tap Ⓐ once per second and see whether the success rate goes to 1" was the next +step this entry named. It was run (`tools/re-capture/menu_draw_capture.sh`), and +the answer is **no**: + +| run | what was pressed | result | +|---|---|---| +| E | **one** Ⓐ on the first title after boot | **main menu** | +| F | **40** × Ⓐ at 1/s on the title, then one each of START, B, BACK, X, Y | title, unchanged | +| G | Ⓐ every 4 s through the whole boot (88 presses) | permanent **black screen**, no crash, never recovers | + +In run F every press was delivered — the driver logs `keystroke vk=5800 down/up` +for each — and the new `[RE-INPUT]` line never fired, so nothing was swallowed. +The guest received them and ignored them. **No button does anything** on that +title: START, B, BACK, X and Y are as inert as Ⓐ +([`captures/title-unresponsive-attract.png`](captures/title-unresponsive-attract.png)). + +Run G is worth its own warning: hammering Ⓐ through the boot is not merely +useless, it **breaks the run** — 88 presses left a black screen that never came +back (no crash, no throw, the emulator healthy). The script no longer taps +during boot; the intro takes ~3.5 minutes and gets to the title by itself. + +**So the difference is not the number of presses or the button.** The one +success came on a title that appeared ~83 s into a warm boot; the failures came +on titles that appeared after 292 s and a full attract cycle. The obvious +reading — that the attract-loop title is a non-interactive presentation and the +post-boot title is the interactive one — is a **hypothesis, unconfirmed**, and it +is what to test next. + ## Still open -Why the acceptance is intermittent. The next step is not another guess: capture -the *first* title's Ⓐ under `--cache_throw_diag`-style logging of the guest's own -state machine, or simply script "tap Ⓐ once per second for 30 s on the first -title" and see whether the success rate goes to 1 — a cheap, honest experiment -that also gives a reliable route to the main menu for the UI paint-order work. +Which title state accepts input, and how to tell them apart from outside. A +`log_ui_draws` capture in each state would say whether the two composite +differently (the interactive one draws `ptbtn00`, the `PRESS Ⓐ BUTTON` plate, +from build 2 — if the attract title omits or replaces it, that is the tell and it +is visible in one capture). Until that is pinned down, reaching the main menu is +a matter of luck, which is not a basis for the second screen's paint-order +capture.