fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs/re: the scripted route to the menu does not work — measured, not assumed

Browse Source 
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.
This commit is contained in:
Sylpheed RE agent
2026-08-18 22:45:08 +00:00
parent 243835719f
commit 4b0263b80f
3 changed files with 45 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/re/BACKLOG.md
View File

@@ -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