User-mode virtual controllers for Windows. No kernel driver, no network, no reboot. DirectInput, XInput, SDL3, the browser Gamepad API, and WGI all see the exact identity of real hardware, down to the bus type.
Three calls
One DLL, HIDMaestro.Core.dll, with the 228-profile catalog, the driver binaries, and the signing tools embedded. Grab it from a release ZIP or build from source.
InstallDriver() is self-bootstrapping: it creates a locally trusted certificate, signs the driver, and installs it. No EV certificate, no test-signing mode, no reboot. When the installed driver already matches, the call completes in ~40-60 ms.
Pick a profile, call CreateController, submit input. A single controller is live in about 200 ms. Dispose it and the device disappears, with no leftover PnP state.
The whole lifecycle is one page of C#. The game on the other side sees an Xbox 360 pad indistinguishable from the real thing.
using var ctx = new HMContext(); ctx.LoadDefaultProfiles(); ctx.InstallDriver(); using var ctrl = ctx.CreateController( ctx.GetProfile("xbox-360-wired")!); ctrl.SubmitState(new HMGamepadState { Buttons = HMButton.A });
Identity
Profile-driven VID/PID, product strings, HID descriptors, axis and button layout, and bus type. A Bluetooth controller reports as Bluetooth, not as a USB device wearing its name. SDL3's controller database matches it, Steam recognizes it, Chrome identifies it, joy.cpl shows the right name.
Embedded profiles across 32 vendors: Xbox 360, Xbox Series, DualSense, Thrustmaster, Logitech, flight sticks, racing wheels, and more. Every controller is a JSON file. Adding support for a new one means writing JSON, not modifying code.
Add a controller by writing a data-only JSON profile or by capturing one you already own. No per-device source code, no recompile, no hardcoded device classes. Adding a controller to a code-per-device emulator means writing and compiling a new device implementation. That difference is the whole point of the profile system.
The Switch Pro Controller is not a passive device: hosts drive a Nintendo subcommand handshake and stall without a device that answers. HIDMaestro's driver answers it over the real Bluetooth wire, with a descriptor extracted byte-exact from a live Pro's SDP cache: SPI calibration reads, input-mode switch, 60 Hz full-mode streaming with gyro and accel. SDL3 and Steam Input bind it as a real Bluetooth Pro Controller with motion and rumble.
A real USB DualSense is a four-interface composite, and three profiles present all four. Windows gets the pad's own Speakers and Headset Microphone endpoints, and the 4-channel stream behind them carries the speaker on channels 1 and 2 and the voice-coil actuators on 3 and 4. That stream is the only path on Windows by which a game hands a controller its authored haptic waveforms. It reaches your code as UsbAudio.Output with each channel's role named. Nothing extra to install: the USB transport ships inside the DLL and deploys itself the first time you create one.
Clone a DualSense and ship a 16-button variant that Windows, Steam, and games still see as a DualSense. Build a flight stick, racing wheel, or arcade panel from scratch with arbitrary VID/PID, axis count, button count, and resolution. Or point HMDeviceExtractor at any controller you have plugged in and get a ready-to-deploy profile back.
Latency
The input number is real propagation, measured over 10,000 single-press iterations and reproducible with one command. See the methodology.
HIDMaestro talks to its driver through shared memory on the same machine. No socket, no USBIP stack, no kernel transport driver in the path. Both directions are event-driven with no batching cap: input signals the driver per frame, and the driver signals each captured rumble/FFB/LED packet back to the consumer at ~0.15 ms median, over 60x faster than the previous 8 ms polled path, with idle controllers costing zero measurable CPU.
VIIPER's published Windows figure, 168 µs, is localhost-only. Running it over an actual network, the thing the project is named for, adds roughly 1 to 5 ms on wired LAN or 10 to 50 ms over Wi-Fi on top of that figure, a caveat its docs mention only in passing. It also batches reports every millisecond, capping the update rate at 1000 Hz. HIDMaestro's input is event-driven with no fixed cap.
Networking belongs in the application, not in the device driver. Tools built on USB/IP put a kernel USBIP driver and a listening socket in front of every user, even for purely local play. USB/IP can also only present USB devices, so a controller paired over Bluetooth shows up with the wrong bus type. HIDMaestro keeps the device layer local and sets bus type per profile, so a Bluetooth controller presents as Bluetooth. Network play still happens, at the right layer: PadForge, built on HIDMaestro, shares controllers across PCs with its Remote Link feature, both directions with feedback returning to the real device, at no cost to local play.
When the installed driver already matches, InstallDriver() completes in ~40-60 ms and a consumer goes from process start to a live controller in about a second. If the consuming app is force-closed mid-session, the next launch evicts the orphaned devices and has the first controller live again in ~2.3 s, measured with an Xbox Series BT profile in the mix, the deepest teardown stack.
Every API
DirectInput sees correct axes and buttons. XInput sees separate triggers in one slot. SDL3/HIDAPI sees the right identity and bus type. The browser sees a STANDARD GAMEPAD with separate triggers. WGI sees one Gamepad. RawInput sees the same device as all of them, at the same time.
A 46-scenario regression battery checks DirectInput, XInput, SDL3, the browser Gamepad API, and WGI on every change, passing on both a 16-core Windows 11 desktop and a low-power Intel Atom Windows 10 machine. A real Xbox Series X|S Bluetooth controller tested side by side shows byte-identical behavior across the HID class APIs.
No hard limit on simultaneous virtual controllers. Tested with 6 mixed types, correct per-controller ordering across every API. XInput caps Xbox-family profiles at its own 4 slots; non-Xbox profiles run beyond it.
Create and remove controllers on the fly, about 200 ms for a single controller. Live-swap a controller's profile mid-session. No reboots, no leftover devices.
HID PID 1.0 answers for DirectInput force-feedback games, plus rumble and haptic output events the consumer routes to real hardware. The driver accepts the writes and raises them to your application in real time.
Compare
HIDMaestro is Windows optimized and focused on game controllers and HID game devices. Within that scope it gives you exact hardware identity with no kernel driver, no network layer, and no per-device code. The composite USB personas are the one deliberate exception: controller audio needs a driver-backed USB device, so those three profiles deploy a signed third-party transport that ships inside the DLL. Pick any other profile and nothing kernel-mode is ever installed.
| HIDMaestro | VIIPER | ViGEmBus | vJoy | WinUHid | |
|---|---|---|---|---|---|
| Kernel driver required | No, except the composite USB personas | Yes (USBIP) | Yes | Yes | No (on VHF) |
| Installs without test-signing | Yes | Yes | Yes | Yes | No |
| Network play | App layer via consumers (PadForge Remote Link) | In the driver: +1-5 ms wired, +10-50 ms Wi-Fi | No | No | No |
| Exact identity, incl. Bluetooth bus | Yes, 228 profiles | USB only | 2 fixed types | Fixed identity | 4 presets, USB only |
| Add a new device | JSON, or capture one you own | Write Go per device | N/A | N/A | Write C, or raw descriptor |
| Local single-press latency | ~35 µs measured | 168 µs published | N/A | N/A | Not published |
| Status | Active | Active | Retired | Stale | Active |
The spec sheet
Short punch list. Each card is one feature. The documentation covers each in full.
Runs entirely in user mode via UMDF2, loaded by a locally trusted self-signed certificate. No test-signing mode, no purchased certificate, no reboot. It installs on a normal PC, not just a developer box, and a bug cannot blue-screen the machine.
Three composite USB personas present the pad's speaker, microphone, and voice-coil actuators, so Windows gets real audio endpoints and a game's authored haptic waveforms reach your code. The USB transport those need is embedded in the same DLL and deploys itself on first use.
Input travels through shared memory on the same machine. No socket, no USBIP stack, no kernel transport driver between your application and the device.
Profile-driven VID/PID, product strings, HID descriptors, and bus type. A Bluetooth controller reports as Bluetooth, not as a USB device wearing its name.
Embedded profiles across 32 vendors: Xbox 360, Xbox Series, DualSense, Thrustmaster, Logitech, flight sticks, racing wheels, and more.
DirectInput, XInput, SDL3/HIDAPI, browser Gamepad, WGI/GameInput, and RawInput all see the same real controller at once.
A 46-scenario regression battery checks DirectInput, XInput, SDL3, the browser Gamepad API, and WGI on every change, passing on both a 16-core Windows 11 desktop and a low-power Intel Atom Windows 10 machine.
Add a controller by writing a data-only JSON profile or capturing one you already own. No per-device source code, no recompile, no hardcoded device classes.
Create and remove controllers on the fly. About 200 ms for a single controller. No reboots, no leftover devices.
No hard limit on simultaneous virtual controllers. Tested with 6 mixed types, correct ordering across every API.
Free and open source. Use it in your own projects, commercial or otherwise, with no restrictions.
See it
HIDMaestro is a developer platform: a C# SDK and a matching user-mode driver.
Clone the repo or grab a release to get started. MIT licensed, free forever.
Prerequisites:
If you want to use HIDMaestro through a UI instead of code, install PadForge. It wraps this SDK with a full input-mapping app.