Each of these presents as "the pad is dead", and each has a different cause. 1. **F10 opens the emulator's menu bar.** It is the RE capture hotkey AND the toolkit's menu key. With that menu open — or any Xenia UI window, the Profiles Menu included — `IsUIActive()` is true, so XamInputGetKeystrokeEx returns SUCCESS with a ZEROED keystroke before the pad driver is asked. The guest polls, gets nothing, and does nothing, with no error anywhere. Escape does not close it; a click on the game surface does. This cost most of an iteration. 2. **The file-pad was never the problem.** It delivers (vk=5800 down/up per tap) and A skips movies in the same runs. 3. **(A) at the title needs a signed-in profile.** Without one the guest calls XamShowSigninUI and Xenia's dialog appears — which is also the proof the guest reads the button. That dialog cannot be completed here: the gamertag is an ImGui text field and synthetic X key events never reach it. Hence Canary's new --create_profile_if_none. And the blocker, stated as measured rather than as a theory: with the profile signed in, (A) still does not advance the title across four boots. The reproducible failure is next door — with the default --mem_watch=true the guest crashes in the boot content path (read of 0x10000000C at 0x82307128, thread 9, after a guest C++ throw), and with --mem_watch=false it does not. That is a second, far cheaper reproduction of the Ready-Room crash the canary handoff blames on the mem_watch probe: 40 s from a cold boot instead of after a mission. One observation kept because it did not reproduce: a single (A) once crashed the guest at a DIFFERENT PC (0x824578A0, thread 6). Two attempts to reproduce it gave neither a crash nor a transition. Next step named: those two PCs in xenia-rs/sylpheed.db, and the content exports around the press.
966 KiB
1279x675px
966 KiB
1279x675px