Explain the way the program will be ran

[AadamZ5]

I am trying to see if I can help out with anything in this project, but I'm having a hard time gathering how this application will be ran. Is this going to be ran alongside steam (sibling processes) or is this application going to be ran as a child of steam, potentially integrating with Steam API? Why is the CEF interface required? It seems less desirable and sound to use a debugging interface as a main form of integration.

Are there any quick links I could read up on to avoid asking someone to explain a bunch of stuff to me? Even pointing to major architecture points in the code would be helpful.

Specifically, I was interested in the "why" of #3, so I was trying to understand "how" this process runs. I do understand that this will create virtual devices to forward steam-input through, so maybe this application runs as a child process of Steam?

[Alia5]

Is this going to be ran alongside steam (sibling processes) or is this application going to be ran as a child of steam

Both are valid options with their own advantages and drawbacks.
I recommend reading up on the usage guides here and there

In essence, it's reliant on the Steam Overlay to grab Steam's virtual controllers in order for them to be re-emulated as more compatible controllers. (Though SISR can operate in a non-Steam mode, too!)

potentially integrating with Steam API

As a non-Steam program, we don't have such luxury :(

Even pointing to major architecture points in the code would be helpful.

I actually used this a learning experience for Rust, which I have never written before, so it's quite a mess, honestly
There will be a bigger update in the next few days (you can already get a peek in the WebUI branch, though I've not yet pushed all changes I have, and I will rebase and recommit once the current functionality is back in place.)
On this branch the UI (and part of the initialization flow) will actually be web-based using the systems-webview and a lot of actions will be exposed via an HTTP-API (that can be called from the SISR UI, as well as Javascript injected into Steam)
It should make the flow of what's happening a bit clearer by itself.

---

Anyway, here's how SISR operates, in essence:

The software uses 4 "main threads" that communicate using events.

1. OS Main thread - Shows a window and optionally renders a transparent layer in borderless-window mode to serve as a target for the Steam Overlay UI and touch-/radial menus
2. A dedicated thread for SDL and gamepad events
3. "A thread" for the tokio-runtime, handling async TCP-requests, such as (but not limited to) calls to VIIPER for controller emulation and the upcoming HTTP-endpoint handlers. (Quotation marks, as it's technically not correct to call it a single thread, but oh well)
4. A tiny thread to handle the system-tray icon.

(Simplified) main flow:

1. Not launched from Steam?

• Load the Steam Overlay (GameOverlayRenderer64.dll/.so)
• Launched from Steam? Great, the overlay is already injected by Steam

2. Unpatch some of the Steam Overlays' function hooks to see Steam virtual as well as real game controllers, simultaneously

3. Check if there is a specific non-Steam shortcut (the SISR marker) and retrieve / calculate it's non-Steam AppID

• call a Steam-protocol link steam://forceinputappid/**AppID**
  This switches to the markers' Steam Input configuration and keeps it no matter what game or application is launched or is in the foreground.

4. Pair the real and Steam Virtual game controllers, and attempt to detect which is which. (This isn't actually that easy as soon as multiple controllers are used :/)

5. Grab all inputs from Steam's virtual controller and forward them to VIIPER for re-emulation as Xbox 360 or DualShock4 controller.

---

Point 3 is also the reason for #3 , as that would allow having SISR as a general background-app alongside Steam and deactivate itself momemtarily when anything is launched from Steam.
Point 3 also has issues when using this in Steam Big Picture mode, as it has its own Steam Input layout (as does the Desktop fallback)

For all of this, Steam, however, allows registering callbacks within the SharedJSContext tab when CEF remote debugging is enabled, so it's easy enough to solve.

[AadamZ5]

@Alia5 Thank you a ton for the detailed write up, it was super helpful. Few questions/clarifications I need about your simplified flow steps:

Check if there is a specific non-Steam shortcut (the SISR marker) and retrieve / calculate it's non-Steam AppID

Where are we checking if there is a non-Steam shortcut, somewhere on the disk or the process's exec?

Pair the real and Steam Virtual game controllers, and attempt to detect which is which. (This isn't actually that easy as soon as multiple controllers are used :/)

The real controller being the physical USB HID device, and the Steam Virtual game controller being... a virtual controller from steam overlay?

---

Below is a little bit of personal rant and also bold "what if" idea

I really wish Steam would break out there monolithic Steam Client into utility applications and services, but I'm sure there's reason they haven't done that. For instance, you'd think that they could engineer exactly what you're trying to make here with all of the internal code they have supporting steam input.

I know you're working within the confines of what is available, but is there any interest in making something to replace steam input? I personally don't like the sound of that idea, but want to share it nonetheless. For example, what if we made a long-running service application that basically provided it's own version of steam input, remapping the physical device to an emulated device. Essentially a full replacement...

I could see some sort of plug-able architecture now to support that idea long term:

  Steam Input architecture composition (existing):


                 Steam Overlay Injection -> SISR virtual-dev-management
                 
                 ^^^^^^^^^^^^^^^^^^^^^^^
                     existing logic


  Full replacement architecture composition:
 

                USB HID -> SISR remapper -> SISR virtual-dev-management
                
                ^^^^^^^    ^^^^^^^^^^^^^    
                  new           new
                  

Above, the SISR remapper could be core code that basically replaces what steam input does. This definitely would need more discussion because I think this idea drastically reduces user experience with not having steam input controllable in one place. Perhaps there could be a way to externally modify steam input files from your own application, who knows.

[Alia5]

Where are we checking if there is a non-Steam shortcut, somewhere on the disk or the process's exec?

To be precise, it actually depends.

a) SISR launched from Steam:
The AppID is read from environment variables that Steam sets on launch (SteamAppId)

b) SISR launched outside of Steam:
It is read from the shortcuts.vdf file from the currently signed in Steam User.
(and subsequently the environment variables are set and the GameOverlayRenderer.dll/so is loaded)

See: runner.rs#L52-L63 (webUI branch)

Note that it would be possible to query this information via Steams CEF remote debugging interface, but reading from the file is a tiny bit more solid than relying on injecting JS into Steam.
See SteamInputDB-Buddy: JS-Template and associated Go code

---

The real controller being the physical USB HID device, and the Steam Virtual game controller being... a virtual controller from steam overlay?

Exactly.
Steam hooks (almost?) all system APIs and hides the real controllers, as I previously said.
Via those hooks, the Steam Overlay also "emulates" the so-called "Steam Virtual Gamepad", which is essentially an Xbox360 / XInput controller with USB VID/PID 0x28de, 0x11ff
There are a few other special things the Steam Virtual Gamepad does, all of which you can find in SDL3s source-code, though.

Note that on Linux-Land things are a bit different, but as it stands SISR is not really required on Linux, and Linux build artifacts (mostly) exist for the ability to "stream" controllers and KB/M from one computer to another (think using a Steam Deck as dedicated controller, without the drawbacks of using USBIP/VirtualHere directly)

---

I know you're working within the confines of what is available, but is there any interest in making something to replace steam input? [...] For example, what if we made a long-running service application that basically provided it's own version of steam input, remapping the physical device to an emulated device. Essentially a full replacement...

I really don't have any interest in replacing Steam Input or developing my own remapper, and I have zero interest in changing the direction of the project.
The design of this software also has nothing to do with working with what is available.
I do have a lot of reasons for this, but expanding on this would be a bit too much for now.

But let me expand on your idea, nonetheless:

The USB HID -> SISR remapper -> SISR virtual-dev-management is pretty simple in principle.
When choosing the right dependencies, this can be made significantly easier, too.

• SDL3 already provides (the imo best) abstractions to interface with (almost?) any gamecontroller like devices, including the new Steam Controller (code was contributed by Valve months ago)
• SDL provides so called "GamePadMappings" which can be set programatically or via environment variables (SDL_HINT_GAMECONTROLLERCONFIG and SDL_HINT_GAMECONTROLLERCONFIG_FILE)
• (There also is an active issue in SDL3s repo regarding an Action Set API
• I do provide VIIPER for input device emulation.
  And a lot of older remappers exist as well that use the (unmaintained) ViGEm-Driver

Most of this can even be supported via SISR, too, actually!

SISR does have a --no-steam flag and does respect the aforementioned SDL_HINTs, so a GUI to create and inject those remapping-strings is really all that would need to be added.

I wouldn't recommend it though, as the focus is entirely different, and a lot of the complexity in SISR (interacting with Steam, unpatching function hooks in native code, pairing Steam's Virtual gamepads to real-gamepads, etc. ) is really not required for this, obviously, and the only reason for existence of the --no-steam-flag is that the implementation was "essentially free", more or less

A remapper / Steam Input replacement would also constitute completely different software, and that point has nothing to do with Steam.

[AadamZ5]

Thanks for the detailed response, and entertaining my thoughts! Forgive me for any naive views or comments, I'm getting up to speed in the game pad world. I just read some info about SDL3 a few days ago, and I think I should look into it more.

I'm hoping to contribute to this project soon, Rust is a lovely language and this project is cool. I will read through some issues soon and hopefully contribute some helpful code 🙂

[Alia5]

Rust is a lovely language

I hate writing Rust >.< I also used this as a learning experience to get a better grips with Rust
And it shows, but the language and it's ecosystem do lend themselves rather well for this project

But exactly because of this, I'd actually be thrilled if someone who knows Rust better than me helped out a bit! :)

Not everything I want to do is poured into issues at this point, and a some of the bug reports are likely due to user error, or actually in VIIPER, so bear that in mind.
If you want to, you're invited to join me on Discord, where we could have a more direct back and forth

[AadamZ5]

@Alia5 Sorry for the delay in response, I'm traveling right now.

But exactly because of this, I'd actually be thrilled if someone who knows Rust better than me helped out a bit! :)

I don't have a ton of professional experience writing Rust, but I'm definitely super interested in the language and have used it on a few personal projects. I wouldn't consider myself an expert, but I definitely have opinions and preferences about how to write what :)

I'd certainly be open to connecting on Discord, and I could try to take a higher-level look at the architecture and current language use to offer up any opinions. I've joined the server and I'll shoot you a message soon when I have a better schedule to chat more directly. I'm pretty busy for about the next week, and I have a move coming up next month so bear with me if I'm a little slow to respond.

[Alia5]

Right as I'm reconsidering rewriting this all in Go 😂