Release held keys/buttons when MKB forwarding stops (no sticky inputs)

forward_mkb_frame early-returned the whole mouse block when mirroring was off or
ImGui wanted the mouse, and the top-level gates returned when the subsystem was
off / focus was lost / the game died. A key or mouse button held at that moment
never got its KeyUp/MouseUp, so it stuck DOWN in the guest -- a held mouse button
fires continuously, a held key walks forever -- contradicting the "send the up so
nothing sticks" intent.

Track what we've forwarded as held (g_mouse_down / g_key_down) and release it
whenever we stop forwarding for any reason: the can't-forward gate, ImGui grabbing
the keyboard/mouse, or the mouse-not-mirroring path all now release held inputs
before returning. Normal down/up still flips the held state.

Fix by inspection: forward_mkb_frame needs a live ImGui context + injection panel,
so it isn't unit-tested; the logic is a straightforward held-state release.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
2026-06-24 01:38:52 +02:00
parent abbc16aa4d
commit 6bdee40219
2 changed files with 51 additions and 17 deletions

View File

@@ -114,8 +114,6 @@ From an in-depth review pass. Each item is fixed test-first (a failing test, the
as its own commit; "verify" items are confirmed real before any change, and dropped if not.
Robustness (verify, then fix if real):
- **`mkb_forward` sticky mouse-up** — a held button isn't released when mirroring toggles off / ImGui
grabs the mouse. Release held buttons.
- **Swallowed audio loopback `start()` failures** — surface a process-loopback activation failure
distinctly from "no correlation" in the verifier + loopback.
- **Permissive injector bitness gate** — `IsWow64Process2` failure is treated as 64-bit; fall back to