5 Commits

Include renames

Author	SHA1	Message	Date
3 people	85cd3f1642	feat(app): debugger halt and GDB stub with the emulation thread on (#967 phase 3b) (#1068) ... * feat(app): bounded halt pump on DebugCore; the UI mirrors the halt DebugCore owns the halt: pump() serves the debug lane, waits at most kPumpWait (4 ms) on a debug-lane-only wait and returns VJ_DBG_RESUME_NONE to GDBHalt's own loop, which keeps the socket service and the halt timeout. The UI writes its verdict tagged with the halt serial it saw, so a verdict for a dead halt never resumes the next one; frameEnded() closes a halt the core left on gdb's say-so. DebugSession mirrors HaltState once per UI frame (syncHalt) and fires onHaltUi / onResumeUi on serial edges; attach/detach/breakNow are ordered through the lane and a pending detach. Inline keeps the nested UI frame. Refs #967 Co-Authored-By: Claude Opus 5.5 <[email protected]> * fix(app): a STEP the core never re-halts must not leave the UI mirror halted pump() returns STEP without bumping the halt serial, so the bar stays up while the core steps. If the frame ends before the core re-halts (the stepped instruction ended it, or the target had stopped), frameEnded() found nothing halted and the mirror stayed halted for good; inline, stepEmulation() is gated on halted(), so the frame that would re-halt never ran and F9 / Detach wrote verdicts nothing took. DebugCore now remembers a STEP in flight (cleared by the next halt entry or setIface) and frameEnded() closes it like a foreign resume. Refs #967 Co-Authored-By: Claude Opus 5.5 <[email protected]> * fix(app): verdicts and detach only against the core's live halt After a STEP verdict the halt serial is unchanged but the core is running until it re-halts, so DebugSession::detach() offered a DETACH for a serial the re-halt then dropped, left detachPending_ set (attach / Break refused) and, with hardcore turning on in that window, left the core attached. resume / step / detachAndResume now require the core's halt to be live (parked, same serial); detach and detachAndResume fall back to the lane detach otherwise, and that post also releases the pump if it runs inside a live halt. haltedFrame() syncs the mirror first so the first nested frame meets the current halt; the inline resume hook keeps headless audio unpaused as before. Refs #967 Co-Authored-By: Claude Opus 5.5 <[email protected]> * feat(app): the emulation thread pumps the halt; quitting ends it Threaded, the pump's wait is App::haltWait (serve the debug lane for at most 4 ms, refill the views when a request is pending); frameEnded() runs after every retro_run so a halt gdb ended is closed on our side (inline: from syncDebug outside a frame). beginQuit() sets quitting_, wakes the pump and waits at most 200 ms for the detach the pump answers with, before the auto-save, the SRAM flush and the 3 s unload; closing the window inside an inline halt takes the same path. haltedFrame runs only inline. The halt bar says "HALTED by gdb" for a halt the app did not ask for; a halt at the CPU window's own temporary breakpoint (run to cursor, step over) is ours (DebugSession::ownsBreakAt). Refs #967 Co-Authored-By: Claude Opus 5.5 <[email protected]> * feat(app): calls and frame advances give up when a halt begins; content changes detach first EmuThread::call and advance take a give-up predicate: a call queued behind a frame that halts returns instead of parking the UI behind the busy spinner; advance registers its budget on the debug lane and waits with the same predicate. Every UI-thread call passes one (App::emuCall). Threaded, open / close / reset / disc detach the debugger first and then proceed; save / load state and boot refuse with a toast; frame-lane posts wait for Continue and the halt bar and the Core options tab say so. Inline keeps refusing (the call would run inside retro_run). RetroAchievements replies ride the debug lane, so none is ever cancelled. Refs #967 Co-Authored-By: Claude Opus 5.5 <[email protected]> * fix(app): a given-up disc follow-up retries; close reports a re-halt; deterministic give-up and re-drain tests followDiscSwap advances seenDiscSwaps_ only when its call ran, so a halt no longer loses the RA / cheats follow-up. closeContent says so when its detach predicate gave up. The netplay headless step stops re-budgeting a frame whose advance gave up. testCallGiveUpLosesToStart covers the compare-and-swap-lost branch of call(), and testAdvanceBudgetDoesNotOvertakeFramePost covers the loop's second frame-lane drain; the 300-iteration smoke loop is gone. Refs #967 Co-Authored-By: Claude Opus 5.5 <[email protected]> * feat(app): the halt and the GDB stub work on the emulation thread; a silent host behind every halt; hardcore locks the stub The phase 1 limits are gone: Break / Step / breakpoints work threaded and virtualjaguar_gdb_stub is a plain option again. Whenever the stub is enabled the app attaches its host on the emulation thread inside the load (before the first frame, so a gdb_wait boot halt is seen) and again after any frame it is missing, so every gdb halt flows through the app's pump: the halt bar shows it, calls give up, quitting detaches. RetroAchievements hardcore locks the stub to disabled at load, and a hardcore flip with the stub open reloads the game so the lock reaches the core (phase 3 plan, decisions 2 and 3). Refs #967 Co-Authored-By: Claude Opus 5.5 <[email protected]> * fix(app): B4 review: pre-frame silent host, gdb halts survive headless inline, Detach clears breakpoints - emuRunOneFrame re-attaches the silent gdb host before the frame, so a gdb halt right after a Detach is hosted - headless inline haltedFrame releases only app halts and quit; gdb's halt keeps the core's socket loop serving - Detach drops the session breakpoint list with the core's table - Settings > Emulation thread hint reflects that the halt and stub work threaded - locked-option warning is generic; a hardcore restart waits out an inline halt Refs #967 Co-Authored-By: Claude Opus 5.5 <[email protected]> * test(app): the halt and the GDB stub end to end on the emulation thread debug_e2e_threaded drives break / step / continue / detach / hardcore / quit from a UI thread that never blocks over 50 ms, pins the option post that applies after Continue, the save state that gives up when a halt begins, a posted lane detach run inside a live halt, the 3 s join, and a gdb_wait boot halt with no client (Detach, quit). gdb_threaded_halt finds a headless run halted at boot from a gdb client, reads memory, continues, and quits the app mid-halt, threaded and inline, plus an inline hardcore variant: SIGINT / SIGTERM end a headless run cleanly (installed after SDL_Init, headless only). The headless inline loop now closes a gdb halt after each frame (frameEnded + syncHalt), without which the hardcore reload retry stays blocked. Refs #967 Co-Authored-By: Claude Opus 5.5 <[email protected]> * fix(app): B5 review: the cancelled save is proven absent after frames run; free ports; signal handler resets debug_e2e_threaded waits for frames after the halt ends before asserting the cancelled save left no file (it is held while halted, so the old check was vacuous) and saves to a different file; the gdb_wait sections probe a free port; the test also fails on ThreadSanitizer. The signal handler restores SIG_DFL after storing the flag (a second signal kills a wedged run) and g_signalQuit is asserted lock-free. gdb_threaded_halt.py's watchdog kills live children; a missing Python3 is reported at configure time. Refs #967 Co-Authored-By: Claude Opus 5.5 <[email protected]> * docs(app): the halt and the GDB stub on the emulation thread Halt model, Detach, hardcore lock and reload, gdb_wait, headless signal quit, testing; README, testing.md, design section 6 (2026-10-22 as-shipped notes), plan 3b task list. Includes the MSVC fix: debug_e2e_threaded includes <ws2tcpip.h> for socklen_t. Refs #967 Co-Authored-By: Claude Opus 5.5 <[email protected]> * fix(app): quitting while a gdb client holds a halt no longer hangs The pump answered a quit with DETACH, which drops the app's host inside the core. A gdb client's breakpoint that is still armed (a hot loop) then fires again at once, with the socket open and no host: the core parks in GDBHalt() for the client, and the quit's flush, autosave and unload wait on it forever. The pump now answers CONTINUE and the host stays attached (unloading drops it). Every wait in the quit epilogue is bounded (flush 1 s, autosave 1.5 s, skipped while the core is still halted); the unload keeps its 3 s backstop. Also: re-attach the silent gdb host before each frame (inline stepEmulation, headless inline loops), comment/doc fixes, EmuThread::stop precondition, and the three gdb tests' PASS regexes lose their ^ anchor. Refs #967 Co-Authored-By: Claude Opus 5.5 <[email protected]> * fix(app): a hardcore restart that gives up stays pending and retries Achievements::pump cleared resetPending_ before the restart and ignored its result. Threaded, the restart can give up when the core halts again (a gdb client with a breakpoint still armed): hardcore was then active without a clean restart and the open GDB stub bypassed the hardcore lock. The restart now stays pending until it takes. reset() returns whether it ran. A give-up with the game still loaded (and, for the reload, the stub still open) retries at the next pump; a restart that failed to load the game, or closed the stub, is dropped. The cheat reset is posted once and the restart is counted once (--ra-expect-reset), the give-up is logged once. Tests: VJ_TEST_RESTART_GIVEUPS=N makes the first N restarts report a give-up (a headless run cannot stage the re-halt); gdb_hardcore_flip_giveup_* (reload path) and ra_hardcore_reset_giveup_* (reset path), inline and threaded. Refs #967 Co-Authored-By: Claude Opus 5.5 <[email protected]> * fix(app): a signalled threaded --neuro headless run still prints the Neuro report The signal-quit block returns before the TIMING/report section; report first (it only touches UI-thread state) so a SIGTERM'd --neuro run behaves like a finished one. Refs #967 Co-Authored-By: Claude Opus 5.5 <[email protected]> * test(app): gdb_* tests take their port from the OS at run time (#967) The six tests with hard-coded ports 23457-23463 (gdb_enabled, gdb_enabled_threaded, gdb_hardcore_flip_*, gdb_hardcore_flip_giveup_*) all failed on the hosted Windows ARM64 runner with 'failed to open port': every one of the distinct ports was refused, which points at a reserved/excluded range, not a collision (the Python gdb tests, which already pick a free port, passed there). tests/with_free_port.py binds 127.0.0.1:0, reads the port back, substitutes {PORT} in the command and, with --config-ini, writes the saved stub setting for the hardcore tests. The assertions and ctest regexes are unchanged. Registered only with Python3 (STATUS message otherwise). RESOURCE_LOCK vj_gdb_port on every test that binds a stub port closes the bind-0 TOCTOU window. Refs #967 Co-Authored-By: Claude Opus 5.5 <[email protected]> * fix(app): start Winsock before the core loads so the GDB stub can bind on Windows (#967) Every gdb_* test that opens the stub failed on hosted Windows x64 with "[GDB] stub enabled but failed to open port N", on fixed and on OS-chosen free ports alike. The core's GDBSockOpen (src/debug/gdbsock.c) calls socket() without WSAStartup, because its libretro host (RetroArch) starts Winsock. The app never did on that path (neuro and netplay only start it for themselves), so socket() failed with WSANOTINITIALISED and the stub stayed disabled. The feature was therefore broken for users on Windows too, not only in tests. platform::initNetworking() now runs WSAStartup once, right after SDL_Init and before any core load, headless runs included. A no-op on macOS and Linux. Winsock is reference counted, so neuro's and netplay's own WSAStartup stay harmless. Also corrects the comments that blamed reserved port ranges. Refs #967 Co-Authored-By: Claude Opus 5.5 <[email protected]> * test(app): with_free_port.py hands the app explicit stdout/stderr (#967) The Packages / Windows x64 job builds the GUI-subsystem exe (VJ_APP_WIN32_GUI). There, gdb_enabled, gdb_enabled_threaded and the gdb_hardcore_flip* tests missed their PASS regexes. Popen(cmd) left the child's standard handles to inheritance, so Windows started the GUI-subsystem app with no stdout. console_attach.cpp then attached the runner's console, and the output never reached ctest's pipe. The wrapper now passes stdin=DEVNULL and stdout/stderr explicitly, so the output stays on the pipe. Tests that ctest launches directly already get redirected handles and were unaffected. Refs #1075 Co-Authored-By: Claude Opus 5.5 <[email protected]> --------- Co-authored-by: Claude Opus 5.5 <[email protected]> Co-authored-by: dry <dry@x>	2026-10-23 02:36:04 -04:00
Joe MattielloandClaude Opus 5.5	337e595810	fix(app): Pro Controller (6-button) device with its own X Y Z L R controls (#1019) ... * fix(app): add the Pro Controller (6-button) device with its own X Y Z L R controls Settings > Input now offers "Pro Controller (6-button)" on both Jaguar ports. The core has no RETRO_DEVICE id for it, only virtualjaguar_pN_device = pad_pro, and the app locks that option to auto, so the core's pro_controller[] flag could never turn on from the app. The option lock now takes the Pro ports into account (lockedCoreOptionFor), and CoreHost::refreshLocks() hands a changed value to the core through GET_VARIABLE_UPDATE. retro_run() runs check_variables() before update_input(), so a switch takes effect on the next frame. The app stores a private id for the device in the joypad class and gives the core a standard pad for it. New controls X / Y / Z / L / R (Pro) are appended after C_TVMENU, so saved ids keep their meaning. On a Pro port the Router presses them as RetroPad X / L2 / R2 / L / R, and the core's Pro path turns those into keypad 9 / 8 / 7 / 4 / 6. They are never synthesised as keypad digits. Gamepad defaults on a Pro port, Genesis 6-button style: A / B / C = East / South / West, X / Y / Z = Left Shoulder / North / Right Shoulder, L / R = the triggers. Keypad 0-4 have no pad button there and are reached through the keypad overlay (Share). 5 / 6 stay on the stick clicks, 7 / 8 / 9 / * on the right stick and # on Guide. The standard-pad defaults are unchanged: a new remap_unit digest, frozen from the tree before this change, covers every control that already existed. The keyboard has no Pro bindings, because A S D / Q E already press keypad 9 8 7 / 4 6, the same wires. The cheat sheet, the controls overlay and the remap table show the Pro buttons for a Pro port. Closes #1017 Co-Authored-By: Claude Opus 5.5 <[email protected]> * fix(app): keep the Pro Controller lock on the emulation thread's owner After #1000 the option state CoreHost keeps for the core (locked_, the session values) belongs to the emulation thread, and the UI reads a published snapshot of it. Three changes follow: - refreshLocks() queues itself through `post` when it is called off the owner. On the owner it bumps the option serial and publishes, so the UI's copy of the locked values follows. - App::proPorts is atomic, because the option lock reads it on the emulation thread. - applyPortDevices() works out each port's kind from the lock's own value, not the UI snapshot, which lags until the queued refresh has run and been pinned. With --emu-thread on, limitFeaturesForEmuThread() replaces the option lock. Its lock called the 2-argument lockedCoreOption(), so pad_pro never reached the core in that mode. It now uses lockedCoreOptionFor() with the Pro ports, as wireHost()'s lock does. Tests: - core_host_thread: a lock value moved from the UI thread reaches the core before the next frame's input (RetroPad X reads as keypad 9 under pad_pro, keypad 0 without), the UI snapshot shows it after a pin, and no owner violations occur. - pro_controller_option_on / _off: the app itself hands the core pad_pro for a config naming the Pro Controller, with the emulation thread on and off. The _on test fails when limitFeaturesForEmuThread() keeps the old lock. Refs #1017 Co-Authored-By: Claude Opus 5.5 <[email protected]> --------- Co-authored-by: Claude Opus 5.5 <[email protected]>	2026-10-17 19:25:04 -04:00
Joe MattielloandClaude Sonnet 5.5	5f21ab7541	feat(app): TV menu action and in-game menu (TV mode phase 1) (#995) ... * feat(app): C_TVMENU action, hold bindings and pad capabilities in remap (#991) Co-Authored-By: Claude Sonnet 5.5 <[email protected]> * feat(app): hold arbiter and release guard for dual-use buttons (#991) Co-Authored-By: Claude Sonnet 5.5 <[email protected]> * feat(app): route hold bindings, the TV-menu toggle and the release guard through input (#991) Co-Authored-By: Claude Sonnet 5.5 <[email protected]> * fix(app): UP edges always reach the hold arbiter; hand-offs mask held inputs and reset the menu latch (#991) Co-Authored-By: Claude Sonnet 5.5 <[email protected]> * feat(app): TV focus model, nav intents and style metrics (#991) Pure units behind the TV shell: LinearFocus/GridFocus/FocusMemory and the A-Z jump helpers, NavInput (newest-direction repeat, stick hysteresis, trigger paging) with the button/key intent tables, and the u = h/1080 style metrics with the 120 ms ease-out tween. Co-Authored-By: Claude Sonnet 5.5 <[email protected]> * feat(app): TV in-game menu logic, App adapter and headless script test (#991) tv::Host + AppHost, the tv::Shell menu model (Resume, Save/Load state slot pickers, Controls, Reset and Close game with a No-first confirm), input ownership while the menu is open (Esc = Back = Resume, F4 and the menu buttons still reach the app), App::menuPause/menuResume (silent, keeps a user pause, netplay does not pause, hardcore refuses), and the --tv-test-script runner with a virtual gamepad plus the tv_menu_headless CTest. Drawing comes in the next part. Co-Authored-By: Claude Sonnet 5.5 <[email protected]> * fix(app): TV menu owns input while open, releases reach the app, Start stays with the app (#991) The menu masks all local input while open (netplay included), refuses pause toggles while it holds the pause, lets key/button releases through, leaves Start with the app, and the headless script drives only its own virtual pad. Confirm pages are [Yes, No] with focus on No. Co-Authored-By: Claude Sonnet 5.5 <[email protected]> * feat(app): TV in-game menu drawing, smoke test and controls hooks (#991) Draws the in-game menu over the dimmed game (rail-and-list, focus ring, hint bar), adds the tv_ui_smoke test, the C_TVMENU row with "Add hold" and the Guide-chord hint in the controls screen, the cheat-sheet row, and a windowed --tv-test-script path for screenshots. Co-Authored-By: Claude Sonnet 5.5 <[email protected]> * fix(app): TV menu final-review fixes: pad caps in the controls screen, deterministic headless tap (#991) On pads without Share, a Share-hold TV-menu binding resolves to Guide-hold, and the controls screen and bind capture use the pad's caps. The headless Share tap is atomic. Also: unfocused rows at body size, wheel scrolls slot pages, withheld hold keys stay out of the core, Back stays in the hint bar, Controls only shows the sheet, no menu toggle during capture, and the menu releases a captured mouse. Co-Authored-By: Claude Sonnet 5.5 <[email protected]> --------- Co-authored-by: Claude Sonnet 5.5 <[email protected]>	2026-10-16 19:47:36 -04:00
Joseph MattielloandClaude Sonnet 5.5	a9a73f3db9	fix(app): report --option on a locked core option; no stick-as-D-pad on analog ports; Esc/F10 wording ... --option naming an option the app forces (alt_inputs, pN_device, ...) is now rejected like an unknown key instead of silently running the forced value; a stale saved value warns. A gamepad's left stick no longer also presses the D-pad where it is the analog axis (gear shift, hat). Co-Authored-By: Claude Sonnet 5.5 <[email protected]>	2026-10-13 01:24:49 -04:00
Joseph MattielloandClaude Sonnet 5.5	edef0ac9f6	feat(app): input devices -- mouse, rotary, analog, driving, paddle, 6D, light gun, Team Tap ... Per-port device picker (global and per game), host-input routing for every non-pad device through the remap layer, Team Tap player slots, mouse capture, a controls cheat-sheet overlay, a Pro Controller keyboard layout, and the core's own remap/device options locked so they cannot fight the app. Co-Authored-By: Claude Sonnet 5.5 <[email protected]>	2026-10-13 00:55:32 -04:00