Luminal Virtual Gamepad Bus — a Windows kernel-mode bus driver that emulates Xbox 360 and DualShock 4 controllers, maintained by the NortheBridge Foundation.
Status: alpha. Builds and produces a driver package; not yet signed or loaded on a machine. See Current state for exactly what has and has not been done.
LuminalVGBus is a fork of ViGEmBus by Nefarius Software Solutions e.U., which was archived on 2 November 2023.
ViGEmBus was not retired for technical reasons. Its end-of-life statement records that a conflict with a registered trademark held by ViGEM GmbH led to a mutual agreement and a transition period beginning July 2023. No bug, security issue, or architectural dead end was cited — the author simply had no time to rebrand seven years of solo-maintained work.
That makes this fork unusually low-risk: the code is sound, the license is permissive, and a rename is the actual remedy for what ended the project. ViGEmBus' own shared header carries the instruction "make sure to change this value if you fork it" next to its device interface GUID. We have.
LuminalShine streams games to
Moonlight clients and must present the client's controller to the host as a real
gamepad. On Windows that requires a kernel-mode bus driver: the emulated child
device reports the compatible ID USB\MS_COMP_XUSB10, which is what causes
Microsoft's in-box xusb22.sys to load on top of it and makes XInput — and
therefore essentially every PC game — see a genuine Xbox controller.
There is no user-mode substitute for this. It cannot be done with UMDF, HID injection, or a service.
Today LuminalShine depends on an archived third-party driver that it neither bundles nor can repair. LuminalVGBus replaces that with a driver we build, sign, and service ourselves.
None, deliberately. LuminalVGD is the virtual display driver and stays that way. The two solve unrelated problems, are written in different languages against different frameworks (LuminalVGD is Rust/UMDF/IddCx; this is C++/KMDF), and have different licenses. They ship independently.
LuminalVGBus is deliberately not a drop-in replacement at the protocol level.
The device interface GUID is new ({3BF5F106-774C-41BD-B6B6-B7790698469C}), so
LuminalVGBus and an existing ViGEmBus installation coexist without
interfering. This matters: many users run DS4Windows, reWASD, or similar tools
that expect ViGEmBus to answer. Had we kept the upstream GUID, both drivers would
answer the same interface and clients would bind to whichever won the race.
What is preserved exactly:
| Preserved | Why |
|---|---|
USB\MS_COMP_XUSB10 compatible ID |
Makes xusb22.sys bind; this is XInput support |
| Emulated USB VID/PID values | Games and tools fingerprint real controller hardware |
| IOCTL numeric values and payload structs | Keeps the client port mechanical, not a rewrite |
What changed:
| Upstream | LuminalVGBus |
|---|---|
Nefarius\ViGEmBus\Gen1 |
NortheBridge\LuminalVGBus\Gen1 |
GUID_DEVINTERFACE_BUSENUM_VIGEM |
GUID_DEVINTERFACE_BUSENUM_LUMINALVGB (new GUID) |
namespace ViGEm::Bus |
namespace Luminal::Bus |
IOCTL_VIGEM_* / VIGEM_* |
IOCTL_LVGB_* / LVGB_* |
ViGEmBus.sys |
LuminalVGBus.sys |
| WPP trace GUID | new GUID |
The shared kernel/user contract (include/LuminalVGBus/) is vendored here rather
than pulled from a client SDK submodule. The bus defines its own protocol.
scripts\build-driver.cmd produces an unsigned x64 driver package —
LuminalVGBus.sys, LuminalVGBus.inf, luminalvgbus.cat — against
WDK 10.0.28000.0. Verified 2026-08-19.
Done:
- Forked from ViGEmBus
master(1.22.0, the final release) and fully rebranded. - Fresh device interface and WPP trace GUIDs.
- Shared contract headers vendored into
include/. - Retargeted from upstream's pinned WDK 10.0.19041.0 to 10.0.28000.0, and
dropped a
POOL_ZERO_DOWN_LEVEL_SUPPORTdefinition that the modern kit now provides itself. - KMDF co-installer sections removed from the INF — co-installers are deprecated
and the
WdfCoInstallerredistributable no longer ships in current WDKs. - x86 target dropped: Windows 10 is end-of-life and Windows 11 has no x86 edition, so an x86 build would be dead weight to compile and sign.
- Version resource reset to 0.1.0.0, retaining the upstream copyright notice alongside ours as BSD-3-Clause requires.
- Build recipe captured in
scripts/build-driver.cmd, including several non-obvious eWDK/MSBuild workarounds documented in docs/BUILDING.md.
Not done yet:
- Never signed and never loaded. The driver has not run on a machine, so nothing about its runtime behaviour is verified. Signing needs an EV certificate — see docs/SIGNING.md.
- ARM64 is not built. The INF declares it; the build script only does x64.
- DMF is still a dependency — roughly 60 call sites, shallow usage.
- No CI, no test app, no client library.
BSD-3-Clause, inherited from ViGEmBus and retained — see LICENSE and NOTICE.md. Clause 3 forbids using the upstream author's name to promote derived work, which is part of why the rebrand is thorough.
Note that this differs from LuminalVGD, which is AGPL-3.0/NALA dual-licensed. Keeping LuminalVGBus permissive is a deliberate choice: as the practical successor to a driver the wider Windows input ecosystem depended on, it is worth more as infrastructure others can adopt than as copyleft.
© 2016-2022 Nefarius Software Solutions e.U. and Contributors © 2026 NortheBridge Foundation