Escape used to be intercepted globally as the remap window's cancel
affordance, so pressing it while listening just exited capture instead
of binding anything. Now it only dismisses the unsaved-changes modal
or the game picker; while a row is listening, Escape falls through to
the normal capture path (alone or as part of a combo), and the VK
table gained the missing entry so it resolves to a real binding.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Everything about how the controller behaves — paddle bindings, both
trackpads, and which kind of pad the game sees — is now configured in one
window and saved per game, rather than spread across tray checkboxes that
applied everywhere at once.
Installed games come from the Start Menu and the packaged-app list. Steam
does not shortcut its library with .lnk files, so its games are read from
the .url shortcuts it does write; Xbox and Store titles register no shortcut
file at all and come from the shell's app list instead. None of these
sources can tell a game from any other program, so the picker searches
rather than scrolls — a saved profile is pinned, everything else is reached
by typing.
Trackpads are configured per pad. The previous pair of toggles could only
ever describe one pad doing one thing, because a single TrackpadMouse
instance was switched between pads by a bool; there are two now. A pad can
move the pointer, scroll, feed the DS4 touchpad, or do nothing, and its
click is an ordinary binding dispatched down the same path as the paddles —
it used to be hardwired to a left click that only fired while that pad drove
the mouse.
Key bindings can carry Ctrl, Alt, Shift and Win. The modifiers ride in the
free top byte of the packed binding, so values written by earlier builds
decode unchanged. Windows is chosen from a toggle rather than pressed: the
Start menu opens before the page is told anything, which is what made that
key unbindable before. Choosing modifiers rather than typing them also keeps
combinations like Alt+Tab from being claimed by the system mid-capture.
Ctrl+Alt+Delete is refused outright, being the Secure Attention Sequence
that no ordinary process can send.
Profiles follow the foreground application, and nothing polls to do it. An
unelevated process cannot subscribe to process-start events — the WMI class
that reports them requires administrator rights, as does an ETW kernel
session — but SetWinEventHook reports foreground changes for the cost of one
hook and no thread. Focus is also the better question than "is it running":
a launcher that starts a game and stays resident answers yes long after the
game has exited. Steam profiles are keyed by app id, which a foreground
window cannot supply, so Steam's manifests are read to map that id to an
install directory; a game's launcher, its anti-cheat service and the game
itself all live under it and all resolve to the same profile.
Auto Mode still decides whether the controller is ours at all, so a profile
only loads while we hold the pad. A balloon names the profile when one
loads, under the notification setting, because a profile that quietly fails
to match is otherwise invisible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Users reported the trackpad going dead after a takeover — haptics still
firing, cursor not moving — and recovering the moment focus moved to
another window or the window in front was closed. Haptics are HID writes
and the virtual pad is ViGEm, so both keep working regardless; SendInput
was the one stage of the pipeline that could fail and leave no trace.
Reproduced on this machine with an elevated Device Manager in front:
- 137 px of movement injected, cursor pinned at (910,781) for 5s
- foreground mmc.exe at High integrity, this process at Medium
- SendInput returned success for every one of those events
That last point decides the shape of the fix. UIPI is documented as
failing the call with ERROR_ACCESS_DENIED, but on Windows 11 26200 the
call reports success and the input is dropped afterwards, so no
return-value check can see it. The condition is only observable by asking,
before injecting, whether the foreground window outranks this process.
So that is what Send now does, on every event:
- one check covers cursor movement, trackpad clicks, paddle buttons and
keys, none of which can be judged from their own result. A blocked
paddle press previously produced no evidence anywhere
- the foreground lookup is cached against the window it describes;
injection happens at report rate, foreground changes do not
- the state changing is what gets logged, not the events: one line
naming the blocker, one when it stops
- the tray balloon says which application is blocking input and that
switching away from it restores the controller, rate-limited to one
per blocker per minute so alt-tabbing cannot spam it
- the check never gates the event. It observes and reports; if it is
ever wrong about a system, the input goes out exactly as before
A foreground process whose token cannot be read is deliberately not
named. From Low integrity, OpenProcess succeeds while OpenProcessToken
fails with ERROR_ACCESS_DENIED, and protected processes refuse it too —
so an unreadable level means unknown, not blocked. Guessing would put a
wrong application's name in front of the user; the snapshot records
"unreadable" instead.
Backing this up, for the causes that produce no error and no integrity
mismatch: injected movement is checked against the cursor actually
moving, which is what catches a cursor clip a game left behind or a hook
filtering injected events. It stays quiet whenever a blocker is already
known, so it cannot contradict the better explanation. A refused call is
still logged with a dropped-event count and a recovery line, as a cheap
catch-all for systems where the call does fail.
The read loop also logs the shape of the first state report it gets.
TrackpadMouse requires 30 bytes where the haptics need 28, so a short
report would produce working haptics and a dead cursor — the same symptom
from a completely different cause, and not one that can be told apart
from a user's description. This machine reports 0x42 at 54 bytes over
USB, which rules it out here but not on transports we have less evidence
for.
EventLog::Write is annotated _Printf_format_string_ so a mismatched
specifier is caught by /analyze. It is not enforced in the normal build,
but these lines are read long after the fact by someone trying to explain
a fault they cannot reproduce, and the paths that log least often are
exactly the ones no test run exercises.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Holding a paddle bound to a letter produced exactly one character. The
emission loop only acts on edges, so a held paddle sent one key-down and
nothing further until release.
That was the correct consequence of the design rather than a fault in the
send path: auto-repeat is not something Windows synthesises for a key it
believes is down. A physical keyboard repeats because its own firmware
keeps sending make codes while the key is held, and Windows forwards each
one. Injected input has no firmware behind it, so the repeat has to be
generated here.
Re-send the press while the paddle is held, after the user's configured
delay and at their configured rate — SPI_GETKEYBOARDDELAY and
SPI_GETKEYBOARDSPEED — so a paddle behaves like the key it is bound to
rather than at a rate invented here. Both are captured at press time, so
the rate cannot shift mid-hold. The read loop already ticks at report
rate, so this is a per-frame elapsed check with no new thread or timer.
Keys only. Mice do not repeat when held, so mouse-button bindings keep
their one-shot behaviour, and gamepad bindings are held state in the pad
report, where a repeat would mean nothing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Press-to-bind only listened to the controller, so the remap window could
offer gamepad buttons and mouse clicks but nothing from the keyboard.
Capture a key press while a row is listening and bind that instead.
Capture happens in the remap page's keydown handler rather than through a
keyboard hook. The page is already focused while listening, and a
low-level hook is a heavy, AV-bait mechanism for a convenience feature.
The page reports the physical KeyboardEvent.code, which KeyInput turns
into a virtual-key code, so a binding made on one layout means the same
physical key on another. Escape stays the cancel affordance and is
deliberately not bindable.
Keys are delivered with SendInput as scan codes rather than virtual keys,
because software that reads scan codes directly sees nothing useful
otherwise. Note that injected input does not reach every game — anti-cheat
and some input paths ignore it — so this is realistically a desktop,
emulator, and browser feature. Gamepad bindings remain the answer in game.
Extended keys are flagged from an explicit set. MapVirtualKey is
documented to report the 0xE0 prefix under MAPVK_VK_TO_VSC_EX but does
not do so for the navigation cluster, which shares scan codes with the
numpad — a test caught Up arrow being delivered as numpad 8.
Labels come from GetKeyNameText against the active layout, so a non-US
keyboard shows its own key names, and are JSON-escaped on the way to the
page: the backslash key really is named "\".
Paddle release tracking now records what the press actually sent instead
of re-reading the binding on release, so rebinding a paddle mid-hold
releases the input that was pressed rather than stranding it down.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
