SISR: turning Steam Input configurations into system-level controllers

What the redirect actually does

SISR stands for Steam Input System Redirector, pronounced scissor, and it redirects Steam Input configurations to the system level, either on localhost or over the network. The mechanism in one sentence: SISR takes controllers it receives from Steam through Steam Input and forwards them as emulated but more compatible controllers, indistinguishable from real hardware, to the operating system. So the pipeline is Steam, then SISR, then the game. The game asks the operating system for a controller, the operating system reports the emulated device, and SISR translates the input arriving from Steam. The reason this matters is that the application in the middle is the difference between a game that supports Steam Input and one that does not, and the emulation is done at a layer the application cannot distinguish from a physical pad.

Why the Steam Input route rather than a driver of its own

The project states that this approach makes SISR unique among controller rebinding tools because it uses the established Steam Input system, which gives access to its full feature set, supports every controller Steam supports, and provides access to thousands of community configurations that are browsable on SteamInputDB. That is the argument in a sentence: rather than maintaining a driver per controller type and a configuration format of its own, SISR reuses Steam's, and inherits the community's work with it. The feature list makes the same point in a different way, promising the full SteamInput feature set while emulating compatible controllers, with the emulated device being either an Xbox 360 controller or a DualShock 4, and with gyro passthrough listed under the DualShock 4 branch. The practical consequence for a user is that a controller they already configured in Steam, in the Steam Input overlay, works in a game that has no Steam Input support at all.

The cases it exists for

The README lists the situations it is meant to address: games with aggressive anti-cheat systems, emulators, Windows Store games and apps, and games with broken Steam Input support. All while still providing the full feature set of Steam Input. Each of those is a different failure. A game with no Steam Input support simply never sees a controller unless the OS reports one. A game with broken Steam Input support gets something worse than nothing, a controller that half works. An emulator usually wants a specific virtual pad rather than a generic one, so the emulation target matters, and SISR offers Xbox 360 and DualShock 4 specifically because those are what emulators and older titles expect. The anti-cheat case is the one to read carefully rather than to act on: the project lists it as a problem SISR can work around, which means a game with a strict policy may forbid exactly this approach.

VIIPER and USBIP instead of ViGEm

The emulated controllers, and the keyboard and mouse, are presented to the system as if they were real hardware, and that is achieved using VIIPER, which requires USBIP. The README contrasts this with the predecessor project GlosSI, noting that SISR does not use the unmaintained ViGEm driver. That is a meaningful engineering choice rather than a detail, because it decides whether the tool keeps working as the operating systems it runs on change, and a driver that is no longer maintained is a driver whose behaviour drifts out of step with the kernel it hooks into. VIIPER and USBIP are the pieces that do the work of attaching a virtual USB device and presenting a controller that the system enumerates like a physical one, and the Go module file pins VIIPER at version 0.9.0.

Networking turns a Steam Deck into a controller

SISR can tunnel and forward Steam Input configurations over the network to other machines, including keyboard and mouse input. The stated purpose is to make it possible to use devices like a Steam Deck as a dedicated controller without the need to stream the entire game. That is the scenario the design serves: the display and the game stay on one machine, the physical input arrives from another, and only the input crosses the network. The alternative would be remote streaming of the whole display, which costs bandwidth and adds latency to the picture rather than to the controls. The README also lists networked operation across computers as a feature, and the module file includes a websocket library alongside an HTTP API framework, which is consistent with a tool that both serves a local interface and exposes a network surface.

Operation modes and the fact that Steam must stay running

Multi-platform support covers Windows and Linux, with multiple operation modes: a standalone background service, which the README marks as to be improved, and a Steam overlay window mode. There is also a Non Steam Mode entry in the feature list. The important operational constraint is stated in an IMPORTANT callout: you do get the full functionality of Steam Input without having to launch your games from Steam, but Steam must still be running in the background. So SISR is not a replacement for Steam, it is a bridge attached to it, and the game is launched outside Steam as usual. The project asks readers to read the introduction post before getting started, which suggests the setup order matters: the redirect has to be established before the game enumerates devices, and the documentation covers that sequence rather than leaving it to be discovered.

The Go codebase and its dependency choices

The module file shows a Go project requiring go 1.27.2, with a dependency list that reads like the feature list. The CLI is built on kong with kong-toml and kong-yaml for configuration files, so the command line and its config share one parser. The HTTP API is huma v2 with coder/websocket for the live connection and rs/cors for cross-origin handling, and the webview is go-webview2 on Windows. fyne.io/systray provides the system tray icon, shirou/gopsutil provides process and system information, and josephspurrier/goversioninfo generates the Windows version resource, which also appears as a tool directive in the module file. The repository layout maps onto the components: an api directory, a cli directory, a cmd directory whose main package is the sisr binary, config, input, steam, tray, webview, a middleware directory, an event directory, a polyhook directory, sdl, a UI directory, and an openapi.yaml describing the API surface alongside a mkdocs configuration for the documentation site.

Building it, and what the project asks of you

The build is driven by a justfile with a Windows shell override, and the targets are ordinary Go build tasks. Listing the available recipes is one of them, and generating the Windows version resource is another.

just --list

goversioninfo -64 -o cmd/sisr/resource.syso versioninfo.json

The project also ships a build_appimage.sh script, a desktop entry file, and a GitHub workflow for snapshots. On maintenance, the picture is mixed but honest. The project carries a WARNING callout saying it is highly experimental work in progress where everything is subject to change and may or may not work, and to expect bugs, crashes and missing features. Against that, the release history is brisk, with v0.6.2 published on 2026-10-11, a dev snapshot the same day, and v0.6.1 on 2026-09-30, and the last push to the repository was on 2026-10-11. The roadmap section marks Xbox One controller emulation, bundling multiple devices into a single controller, and automatic HidHide integration as still to come. The licence is GPL-3.0, with the notice naming Peter Repukat for 2025 and 2026.

Editorial conclusion

Use SISR when a game or application refuses to work with Steam Input, or when you want a Steam Deck to act as a controller for another machine, because the emulated devices appear at the system level and the network mode avoids streaming the whole display. Do not deploy it where an anti-cheat policy forbids input emulation, since the README lists aggressive anti-cheat systems as one of the cases it is meant to work around and that is a decision about the rules of a particular game, not about the tool. Verify first that your platform and kernel support the USBIP path, that Steam is running in the background even though you do not launch the game from it, and that you accept the project's own warning, which calls the work highly experimental with bugs, crashes and missing features expected.

Frequently asked questions

Official sources

1. Alia5/SISR on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases