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

docs/re: my own flag hypothesis fails its test, and the input path is mapped

Browse Source 
With the capture cvar gone from the launch line entirely, a fresh run reached the
boot title and (A) still did nothing. The flag is therefore not necessary for the
failure, and 0-of-7-with vs 4-of-6-without does not survive as an explanation.

The conclusion is the plain one: (A) at the title succeeds about half the time
and nothing measurable from outside predicts which. Five candidates are now
eliminated — Xenia UI swallowing the keystroke, the driver filter, a sign-in or
content call on the press, the age of the title, and the capture cvar.

So the guest side was traced instead. XamInputGetKeystrokeEx has exactly one
caller in the title, and that has one caller: entry_point -> main loop
(sub_8216EA68) -> per-frame input update (sub_822F1AA8) -> the pad poll
(sub_82457038). The poller's layout is readable and matches the runtime trace
(keystroke queue at +68/+72 drained with flags=3; current state at +36 compared
field-by-field against the previous at +52), and nothing in it is state-gated.
Whatever ignores (A) is a consumer further up — a real RE job, and that is where
the thread now stands, stated rather than guessed at again.
This commit is contained in:
Sylpheed RE agent
2026-08-19 00:47:53 +00:00
parent 6b26087bea
commit 2483b7c3c9
2 changed files with 55 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/re/BACKLOG.md
View File

@@ -176,9 +176,14 @@ main menu has been reached (screenshot in
successes without `--log_ui_draws`, 0 of 7 with it. An interleaved series
**refuted the boot-time confound** (the latest title of all, 268 s, accepted Ⓐ;
a 232 s title refused), and no mechanism exists for the flag — it is read only
when F10 arms a capture, and F10 was never pressed. The variable has been removed
rather than believed: F10 now arms the capture unconditionally, so navigation
runs need no flag. Until that
when F10 arms a capture, and F10 was never pressed. The variable was removed rather than
believed — F10 now arms the capture unconditionally — and with it gone a fresh
run **still** failed, so the flag is not the cause either. Net: Ⓐ succeeds about
half the time and nothing measurable predicts which; five explanations are
eliminated. The input path is now mapped statically (`entry_point` →
`sub_8216EA68` main loop → `sub_822F1AA8` per-frame input → `sub_82457038` pad
poll → `XamInputGetKeystrokeEx`), and the poll itself is not state-gated, so the
gate is in a consumer further up. Until that
is separated, capturing a screen *and* navigating to it in the same run is not
dependable. The earlier claim, kept: the title that ends the boot sequence
accepts a single Ⓐ (2 of 2 at the time); the title the attract loop returns to