With another program's rebranded ViGEm already on the machine, setup's driver
install silently does nothing and reports success. The user finds out when
they click Enable Steamless Mode and no controller reaches the game. Reported
in #68, where the only ViGEm driver package left afterwards was the Oculus
fork's; running the ViGEmBus installer by hand then offered Modify/Repair/
Remove rather than a fresh install, so the bundle had registered itself
without a working driver ever landing.
Everything downstream of that — the connect failures, the retry storm, and on
1.13 the device cycling that stranded a reporter's HID collections — starts
here. The preceding commits make that state survivable and diagnosable; this
one keeps it from being reached.
Setup now asks the same question the app asks at runtime: is a device
publishing the ViGEm bus interface present? Every cheaper check was measured
and found to lie. The bundle exits 0 when it detects a related product and
declines to act, so the exit code says nothing. The registry records the
product whether or not a driver landed. And the driver's version is no guide
either, since 1.22.0 ships a binary still stamped 1.21.442.0 — which cost an
afternoon before it was pinned down.
ViGEmBusProbe carries the check, and is installed rather than left a build
artefact: its other job is being the thing to ask a user to run when a
controller never reaches a game. Exit code 0 means at least one usable bus,
1 means none. Verified both directions against a real bus and a disabled one.
A failed check does not fail the install. The app is fine, and it now picks
the driver up on its own once it appears, so the message says what to install
and that no reinstall is needed afterwards. Silent installs log the finding
instead of stopping on a dialog nobody is present to close.
It informs rather than repairs. Running msiexec /fa or the bundle's own repair
would be acting on shared-identity MSIs on the one kind of machine known to
have other products' drivers registered against them, which is not a risk
worth taking to save a download.
The installer code itself is unverified: there is no Inno Setup on the machine
this was written on, so the Pascal has not been compiled and no install has
been run. It also assumes ssPostInstall follows the non-postinstall [Run]
entries. That assumption fails loudly if wrong — every healthy install would
warn — which is why the check sits there rather than behind a wrapper built to
guarantee the ordering.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Covers the per-game control profile work since 1.14. Paddle bindings, both
trackpads and the virtual pad's platform are configured in one window and
can be saved per game, replacing the tray checkboxes that applied to
everything at once. The saved profile follows whichever game is in front,
and key bindings can now carry Ctrl, Alt, Shift and Win.
Existing settings are read forward rather than reset. Values written by
earlier builds decode unchanged — the modifier field occupies bits that were
always zero — and the retired trackpad toggles are converted once into the
per-pad equivalent they described: the pad that drove the mouse becomes a
pointer whose click is the left button it was always hardwired to, and on
PlayStation the other pad keeps feeding the DS4 touchpad, which is what it
had been doing all along.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Covers the disabled-devnode work since 1.13. A device cycle switches the
devnode off and back on about a second later, and the disable is global —
it lands in the registry at once and outlives the process, a replug, and a
reboot. Killing the app inside that second left the controller switched
off with nothing running to put it back, recoverable only through Device
Manager. The intent to disable is now recorded before the disable and
cleared only once the devnode confirms it is back, so an unfinished cycle
is undone on the next run.
A devnode disabled by something else — Device Manager, regedit, pnputil, a
tool that hides HID devices — is no longer indistinguishable from an empty
USB port. It is named at startup and can be switched back on from the tray
rather than silently, since it may well be deliberate.
Also adds a heartbeat to the event log. Idle and stopped previously looked
identical there, which is what made the fault behind this release hard to
read after the fact.
Still the only place carrying the app version, and nothing in the app
compares version strings.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Covers the input-blocking work since 1.12: the app now detects when
Windows is discarding what it injects — an elevated window in the
foreground blocks it, and haptics keep working throughout, so the
controller looks alive while the trackpad and buttons do nothing — names
the application responsible in a tray balloon, and records enough in the
event log to tell that apart from a cursor clip, a filtering hook, or a
state report too short for the trackpad path.
1.12 was cut from a working-tree edit that was never committed, so it has
no commit of its own and the version history steps 1.11 to 1.13. The
released 1.12 build carried the same code as 1.11.
Still the only place carrying the app version, and nothing in the app
compares version strings.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Covers the two fixes since 1.10: trackpad haptics were playing on the
opposite pad, and a failed controller handoff now reports which process
is actually holding the device rather than assuming Steam is.
Still the only place carrying the app version, and nothing in the app
compares version strings.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Covers the two fixes merged since 1.9: manual mode can now take the
controller back from a running Steam (#53), and a failed ViGEm target add
no longer orphans a pad that holds an XInput slot until reboot (#52).
The installer script is still the only place carrying the app version, and
nothing in the app compares version strings -- AppVersion is a display and
registry value only, with no VersionInfoVersion field derived from it. So
1.10 sorting below 1.9 lexically has no effect beyond how it reads in
Programs and Features.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Matches the README, which advertises Bluetooth support as new in 1.9.
The installer script is the only place carrying the app version.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Control modes (tray 'Control Mode' submenu, persisted):
- Manual: tray toggle only (grayed labels now explain why when disabled)
- Auto - Off while Steam running: yield the controller whenever steam.exe
runs; reclaim ~6s after it exits (debounced against Steam self-restarts)
- Auto - Off ONLY while in Steam game: yield only while RunningAppID != 0
SteamWatcher polls the Steam process and RunningAppID every 2s with
asymmetric debounce: transitions toward more Steam activity are reported
immediately (yield fast), transitions away must hold ~6s.
Taking the device from a running Steam requires invalidating its HID write
handle. A new elevated helper (SteamlessDeviceCycle.exe) restarts the
controller device node (unplug/replug equivalent) on demand via a
highest-privileges scheduled task, registered by the installer or a one-time
UAC prompt. The tray app itself NEVER runs elevated: an elevated foreground
window blocks unelevated SendInput via UIPI, which froze Steam Input's
desktop cursor whenever the tray menu was open. The same cycle mechanism
hands the device to an already-running Steam on game launch (Steam only
opens controllers on arrival events).
Crash safety: an unhandled-exception filter best-effort restores lizard
mode without taking locks; the firmware's own revert timeout remains the
final fallback. ClaimExclusive now restores shared access on failure
instead of leaving the device handle closed.
Diagnostics for field disconnect reports:
- Event log at %LOCALAPPDATA%\SteamlessController\events.log (512KB
rotation, read-shareable): connect/disconnect causes, game mode
transitions with failure reasons, battery changes, stalls, keepalive
failures, auto-mode decisions. 'Open Event Log' in the tray menu.
- Silent-stall detection: no reports for 4s while enumerated (battery
death, sleep, wireless drop) is now detected, logged, and alerted with
the last battery reading.
- Disconnect/stall alert balloons, suppressed for intentional handoffs,
with a 'Disconnect Notifications' toggle for users with odd setups.
Startup reverts to the plain HKCU Run key (the elevated-logon-task variant
from an interim build is migrated back and cleaned up). Installer ships and
registers the helper and unregisters it on uninstall; version 1.8.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The core fix: the SC2026 firmware silently reverts to lizard mode (including
its autonomous click haptics) after a period without host feature reports,
which doubled up with software haptics as a crunchy burst. A keepalive now
re-asserts the lizard-off state every 2 seconds while game mode is active.
Haptics reliability and feel:
- Switch trackpad haptics from OUT_HAPTIC_PULSE (grip LRAs) to
OUT_HAPTIC_COMMAND (trackpad LRAs) for localized feel
- Click haptic latch: press fires off the debounced firmware click bit,
release only fires once contact area returns to idle, so force chatter
and mid-hold easing cannot re-fire
- Movement ticks: distance-based with motion deadzone, post-release and
first-touch grace windows, pressing/teleport gates (pause, not reset),
idle decay, and a 50ms send rate limit so firmware waveforms never queue
into a backlog
Handoff and mouse:
- EnableLizardMode now also sends LOAD_DEFAULT_SETTINGS so firmware mouse
emulation resumes immediately on disable instead of waiting for the
firmware revert timeout
- Trackpad mouse: carry sub-pixel movement remainders between frames and
retune sensitivity (0.015 -> 0.01125)
Also: shared/exclusive HID reopen support, local-only HapticTester tool
(gitignored, conditional CMake target), installer version bump to 1.7.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Each connected controller now gets its own virtual Xbox 360 device via
ViGEmBus, mapping to separate XInput player slots (1, 2, 3...).
Key changes:
- SteamController: add EnumerateAll() to probe and return all live
device paths across wired (0x1302) and dongle (0x1304) PIDs; add
Open(path) overload to open a specific already-validated path.
- ControllerManager: replace single-controller state with a vector of
Slot structs, each owning its own SteamController, VirtualController,
TrackpadMouse, and read thread. SyncDevices() diffs live paths against
current slots on every device-change event, adding new controllers and
removing disconnected ones. Controllers hot-plugged while game mode is
active are automatically brought into game mode.
- Bump installer version to 1.3.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Start with Windows toggle in tray menu — writes/removes the Run registry
key so the app launches automatically at login
- Inno Setup installer script for packaging the release exe
- CMakePresets.json for named debug/release build configurations
- README updated with correct Visual Studio 2025 build commands and a
note for VS 2022 users
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
