Valve released a new Steam Deck Beta update that includes a useful tweak to its Xbox controller detection.
There’s a bit of a problem with modern Xbox controllers and Bluetooth, where they won’t properly connect up with SteamOS / Linux unless they’ve gone through a firmware update. I’ve seen a lot of support requests about this issue over the years and so it’s good to see Valve highlight it directly. While it’s a Steam Deck Beta Client update, it should apply to other SteamOS devices too.
It’s hard to fault Steam’s controller layer, but I really wish they finally found a way to parse gyro data from third party controllers without having to run them on Switch mode. That goes for Microsoft and their own drivers. At this point it’s weird to keep pretending the Windows controller APIs are supposed to work on their first party Xbox controllers only.
It’s not possible as xinput doesn’t support gyroscopes, the controller simply doesn’t report that data. The “Switch” mode is setting it to be a mostly standard HID/DirectInput device so that all of those inputs can be accessed, but that requires something (Steam Input) to sit between the controller and the game to map the inputs together, and the game has to also support non-xinput controllers - otherwise you are just mapping them back to xbox inputs. The exception is a game that support directinput… well, directly. Like sim racers etc.
There is now the option of going “hardware” Steam Input as well, as is done by the HORIPAD for Steam, but it is something the controller has to do.
Yes, I’m aware, that’s why I’m calling out it’s weird that XInput doesn’t support gyro, because we’re a long way away of it being just based on Xbox controller support and a whole bunch of other controllers with a whole bunch of other features now go through it. If MS doesn’t want to add gyro that’s up to them, but Windows supporting it natively is way overdue. Of course at that point older controllers would probably need a firmware update, but hey, we’ll cross that bridge when we get to it.
In practice the situation we’re having is games are defaulting to Xinput and relying on Steam Input as an intermediate layer for additional features, so the end result is that gyro is… not NOT supported, but often not acknowledged at all, so you end up with a bunch of situations where you have to config gyro manually per game as a bit of a Steam-level hack, and then your controller is all wonky anywhere other than Steam because the way Switch/DI/PS input modes get picked up in non-Steam stuff can be weird.
And it gets worse in handhelds where you’re absolutely at the mercy of how the manufacturer decided to set up their controller and gyro support, and sometimes need to do a lot of weird stuff to pass it on outside of Steam.
It’s the jankiest part of controller set up left on PC gaming, and it’s all down to this weird “mom and dad aren’t talking” dance where MS keeps pretending PC controllers are fundamentally Xbox controllers at the XInput layer and Steam is the de facto curator of the controller support but has no interest (and to be frank no expectation or need) to have their controller layer work outside their launcher.
Researching this a bit more, there is an answer in the making already - GameInput. How long that will take to take over from every game using xinput is left to be seen.
That’s interesting, but considering this note:
I’m really not sure this would do what we both want it to do. If everybody has had a GameInput version of their controller support since last-gen and we’re still getting limited to the XInput feature set I don’t think it sorts out gyro-on-Xinput at all. I am not familiar with the behind the scenes of how modern engine controller code is handled, but this sounds like maybe it’s how games with native PS controller support are doing that, but not necessarily a new standard that will allow the default XInput PC setting of new controllers to pass gyro input to games detecting them as an XInput device. I think it’s more like MS’s answer to Steam Input as an additional layer between the games and the hardware, regardless of what the hardware is using.
It does show that all the tools are in place. MS has control over all the involved APIs. They could expand the Xbox controller API feature set tomorrow, whether or not they add the hardware feature to their base controller model. They just… don’t. And Steam could deploy a Steam-independent Steam Input driver or software to just take over all controller support on a dedicated full-feature OS layer, but they also don’t (on either Windows or Linux, as far as I can tell).
Honestly, there are enough workarounds (add games as non-Steam games, use Switch modes and so on), I just bump against the edge cases of it often because I’m both a controller and handheld nerd, so I’m stuck with a GPD Win handheld that insists on injecting their internal gyro as mouse inputs, which confuses the hell out of half the games, along with a bunch of GameSir and Gullikit controllers that do weird things with gyro, like injecting it at the firmware level instead of passing it to the OS. And I mess around with enough emulators to also end up with “oh, this was on DI mode when I booted RetroArch, so now all my buttons are in the wrong places until I quit”. It’s only dumb for like ten of us… but man, is it dumb.
No, they couldn’t. There’s over 20 years of legacy hardware and software that expects Xinput data to be returned exactly in this format:
typedef struct _XINPUT_GAMEPAD { WORD wButtons; BYTE bLeftTrigger; BYTE bRightTrigger; SHORT sThumbLX; SHORT sThumbLY; SHORT sThumbRX; SHORT sThumbRY; } XINPUT_GAMEPAD, *PXINPUT_GAMEPAD;Changing any of that would break every single xinput controller and game made in the last 20 years. Modifications require a new API, which is exactly what GameInput is.
There are definitely ways to send backwards compatible data when required and separately support additional features in a new iteration of an API. This wouldn’t be in the top 10 backwards compatibility challenges MS has figured out.
But in any case, I don’t care if they call it XInput2 or Game Input. I just need it to support all controller features in all games. It’s a bit hard to tell whether Game Input will ever do that, but so far it seems more concerned with acting as a layer to explicitly support a bunch of different hardware, each with its own standards, than a XInput replacement for controllers. There doesn’t seem to be a concept for a “Game Input controller” there at all, actually, just supported controllers you can listen for regardless of what they’re sending through.
I guess over time if they stick with it and it does end up working as a Steam Input-style intermediary layer that just recognizes anything you’d just ship controllers that match whatever format with gyro support and Game Input-enabled games would just pick them up fine more or less universally, but that doesn’t seem to be what it does right now, or at least not something that either games or manufacturers are relying upon.
Anyway, this was interesting and informative, but I think I’m good now. I definitely don’t want to have a conversation formatted as an argument in which nobody is disagreeing with anybody else. Those are exhausting.
Agreed :)
And no matter how they do it, it’s clear they need to make changes; “everything is an Xbox controller and now just works” actually was pretty nice solution 20 years ago to fix the complicated mess that was PC gamepads with DirectInput, but it is very much outdated idea today.
Thankfully it appears changes are happening that might solve the issue in the near future, and all we can really do is wait and see.