We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
VirtualControllerType enum identifier is Xbox (not Microsoft — that's only the XmlEnum on-disk back-compat name)
ViewModels: add NavControllerItemViewModel.IsVirtualControllerConnected; fix EngineStatusBrush colors (RedBrush stopped, not Gray)
Settings-and-Serialization: MappingRow CombineExpression description, semicolon pseudo-period
Settings-and-Serialization: name the Rumble-action VM fields explicitly; drop semicolon pseudo-period
Settings-and-Serialization: fix table-cell '|. |' default-cell typos; extend MacroData / ActionData tables with v3.1+ lightbar and v3.2 trigger fields
Engine-Library: add missing TargetKind to PadForge.Engine.Common.Mapping helper list
Engine-Library: SDL_GAMEPAD_BUTTON_COUNT is 26 (not 21); add missing constants 15-25 (MISC1, paddles, TOUCHPAD, MISC2-6)
HIDMaestro-Deep-Dive: filter logic exists in three other places (matched the bullet count)
SDL3-Integration: drop stale Step 1 PnP-walk filter-resync claim; fix table-cell semicolon pseudo-period
SDL3-Integration / Engine-Library: PadForge binds SDL_GetGamepadPowerInfo (returns int), not SDL_GetJoystickPowerInfo (returns SDL_PowerState)
Force-Feedback: dispatcher uses SonyEffectWriter raw WriteFile, not SDL_SendGamepadEffect (the latter is the DualSensePassthroughDispatcher path for game-driven AT)
SDL3 rumble fn is SDL_RumbleJoystick, not SDL_RumbleGamepad (fix 5 wiki sites + release notes draft)
Services-Layer: Step5 per-slot diff lives at lines 599-614 (HMaestroVirtualController profile-change check), not 595-604
HM filter surfaces: Step 1 has no HM filter; the four real surfaces are SDL3 fork, OpenXInput fork, XboxImpulseHidWriter, HidHideController
SDL3-Integration: HM filter uses HIDMAESTRO substring + hardware-ID list walk (not container-ID-to-root-enumerator); FeedbackReceived → OutputReceived
Virtual-Controllers diagram: HMController exposes SubmitState (not SubmitGamepadState — that's the PadForge IVirtualController method)
Build-and-Publish: MIDI Services SDK is downloaded at runtime, not bundled in the repo
Architecture-Overview: HIDMaestro driver is bundled in HIDMaestro.Core.dll, not downloaded by DriverInstaller
Adaptive-Triggers: game writes DS5 effect block to USB 0x02 / BT 0x31 (no scePad API on PC)
Architecture/Input-Pipeline: HMController.SubmitState (not HMContext); rewrite reverse data flow against per-family writer dispatch
HM SDK event is OutputReceived, not FeedbackReceived (Virtual-Controllers, Input-Pipeline)
Polish: Xbox writer HID-not-XUSB, fold ScpVBus comparison to ViGEm+vJoy, list v3.2 effect-writer files in tree, fix Adaptive-Triggers sentence
Force-Feedback: Sony rumble path follows UserEffectsDispatcher sole-writer architecture, not HM-relayed passthrough
Polish: drop stale v2.2.1 version markers, banned 'Essential' wording, image-caption em-dashes
Polish: more pseudo-period semicolons fixed; correct stale v2-dev branch refs in Build-and-Publish
Strip em-dash pseudo-colons and pseudo-period semicolons across wiki prose
ViewModels: HIDMaestro registers itself via HMContext.InstallDriver(), not DriverInstaller Driver Status: HIDMaestro section said: 'The user-mode driver still needs to be installed once, which DriverInstaller handles on first run from Settings.' Contradicts Driver-Installation-Internals.md line 5 ('It is not installed by DriverInstaller') and the actual code path (HMContext.InstallDriver() called from InputManager.Step5.VirtualDevices.cs:EnsureHMaestroContext on first engine start). Rewrote to attribute the registration to the engine-side path with the file:method citation.
Driver-Installation-Internals: don't suggest Device Manager removal for HM The 'remove HIDMaestro driver' paragraph told readers to 'remove it manually via Device Manager.' Per project memory rule hidmaestro-not-a-normal-driver-removal.md, HM doesn't behave like an ordinary user-mode driver and Device Manager / pnputil /delete-driver removal is not supported. Same guidance now lives in Driver-Management.md's Uninstall section. Replaced with: deleting PadForge leaves HM registered but inert (no virtual-device creation requests = nothing for the driver to service).
Home: Driver Installation Internals dev-nav row attributes HM correctly The wiki nav row claimed Driver-Installation-Internals covers 'DriverInstaller class. HIDMaestro INF install. HidHide WiX bootstrapper. Windows MIDI Services release query.' Putting 'HIDMaestro INF install' alongside the other DriverInstaller items suggested DriverInstaller installs HM. It doesn't (see Driver-Installation-Internals.md line 5). HM registers itself in the engine via HMContext.InstallDriver(). Rewrote the row to drop the HM-INF-install claim from the DriverInstaller bullet list and add a parenthetical note pointing HM at the engine-side path.
Build-and-Publish: HIDMaestro install path matches Driver-Installation-Internals The native-deps section said: 'The HIDMaestro user-mode driver is installed by a separate bundled installer that DriverInstaller runs on first launch. The driver is not embedded in the EXE.' Three things wrong: 1. DriverInstaller does NOT manage HIDMaestro install (per Driver-Installation-Internals.md line 5). 2. There is no separate bundled installer EXE. The driver binaries ship inside HIDMaestro.Core.dll, which is bundled into the single-file EXE. 3. The driver IS embedded in the EXE (via the .Core.dll bundle). Rewrote to match the actual install path: HMContext.InstallDriver() runs from the engine, in-process, on first start, calling pnputil under PadForge's already-elevated process token. Also tightened the MIDI Services Install description from 'installed on demand from the Microsoft Store or installer' to match DriverInstaller's actual flow (GitHub releases API download + silent install).