fabi/Sylpheed
1
0
Fork 0
Code Issues 9 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 ec5b4d0016
commit 6fd8cd34f2
2 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

42
docs/re/canary-scripted-input-traps.md
View File

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