It’s been well over a year since Valve has released their little beasty of an input device dubbed “Steam Controller”.
When Valve first announced it and stated that this thing should be as hackable as possible, I naturally got excited about the device and so I’ve picked one up short after launch.
About a month after launch, I wrote up a general overview of the controller here.
In the article I briefly touched on the software development side of things, stating that I’d wish for an open API.
I concluded that it’s going to be interesting to see how things shake out,
and ended with this quote from Valve from the original Controller announcement.
“The Steam Controller was designed from the ground up to be hackable… We plan to make tools available that will enable users to participate in all aspects of the experience, from industrial design to electrical engineering.”
So what have we seen so far?
On the hardware side, Valve has made the CAD files publicly available, but there was pretty much nothing except stuff like 3D-printed backplates with wireless dongle holders and LED-swaps. Nothing significant here.
On the software side, things look a bit different.
Valve has done a pretty god job at patching their Steam client and extending the functionality, they even added support in their controller configurator for any other gamepad, not just the Steam Controller.
As I’ve mentioned over a year ago the protocol used by the controller has been reverse engineered (For those wondering: It doesn’t use DInput / XInput)
and the standalone Linux driver is still around but now there also is a GUI for it.
Aside from that, we’ve got “Steam Controller Singer“, a basic Midi player using the haptic engines from the touchpads, fun for a while, but nothing useful, really.
We still do not have the open API I wished for over a year ago, whether official nor unofficial.
And I’m not the only one that would like to see an open API or even the complete Steam Controller software to be open sourced as a whole.
Lars Doucet wrote up an affirmative business case for Valve to open source the Steam Controller software.
Aside from the API and third party driver side, what else is out there?
For the problem of non-Steam games that don’t play nice with Steam’s overlay, like but not only, UWP Games, getting XInput / DInput to work with them, is (or rather was) still a problem.
A Redditor has found a (clunky) way to enjoy them with the Steam Controller with a modified desktop config, though.
Valve, however, decided to remove XInput bindings from desktop configs as “they never worked” anyway.
They later readded them, just to remove them again later… (Make up your minds, Valve!)
That’s pretty much all there is and with that in mind, I am a bit disappointed here, to say the least.
I personally sought out to get XInput bindings to work with problematic titles in a more user-friendly way and thus created a handy little application that aims to do exactly that:
GloSC
With GloSC, short for Global Steam Controller, you do not only get a system-wide XInput device from the Steam Controller but also a “system-wide” Steam overlay to be able to use touch- and radial menus and other overlay-dependent functionality, in any “non-Steam” scenario.
All complete with per application bindings and working rumble emulation.
“Non-Steam” because you still do need a running Steam instance while using it. I didn’t want to lose or recode all the rebinding option Steam already has.
I rushed my project out a bit when Valve first hid XInput bindings from desktop configs but it’s obviously come a long way since then.
GloSC got mentioned from Valve in the Steam client beta changelog from the 9. of January and has been, for better or for worse, may or may not involved in the second removal from XInput bindings in desktop configurations… (Sorry… ?)
GloSC creates a transparent, clickthrough, always on top window for Steam to draw its overlay in and pipes every XInput-input to ViGEm, the “Virtual Gamepad Emulation Framework”
Because of ViGEm currently only being available for Windows 10, GloSCs Gamepad emulation also only works on Windows 10.
It’s also worth noting that, the current public release of GloSC doesn’t work with recent Steam client betas and has a few issues and bugs here and there.
Most of them are already fixed in the source, though.
Because of the lack of any API for the Steam Controller and lacking options in the Steam client, GloSC, unfortunately, has to hook into the Steam client to enable per application bindings. (And thus Steam must be running)
I do get questions here and there about how that works and how I found the specific place to hook, so
you can read up on that and a few other technicalities in part two of this blog post. (With lots of code and assembly)
Continue Reading: Part 2 – My take on it ⟶
And for those asking:
While a Linux (and MacOS…) port is theoretically possible, I won’t personally put any time in that as I only use my Steam Controller on Windows, and for Linux, there is the previously mentioned standalone driver.