Steam Input Wrapper needs to support more than 4 players

[turtle]

Killer Queen Black just launched 8 player support and Steam Input can't handle this.

Why is Steam Input still relying on xinput on Windows? Windows.Gaming.Input supports any number controllers and actually supports XB1 controller trigger force feedback. By not having this on Steam Input you're crippling devs for local multi-player games.

Please make these changes to the wrapper for the Windows client!

Change the wrapper:
https://steamcommunity.com/groups/morethan4localmultiplayer/discussions/0/135514823815481232/

[austinp_valve]

We can't do this because windows.gaming.input doesn't work in the background. We've spoken to the Microsoft input team about this both over email and in person, but to no avail.
We can support up to 16 Xbox controllers over directinput but that doesn't allow us to rumble or use the triggers at the same time so this isn't enabled in Steam. If you're interested in technical details there is a thread on the SDL2 forums where Slouken talks about this in more detail. I know that someone had worked on a pull request where they would switch input apis based on the number of controllers attached but last time I checked it was not yet stable enough to merge.

We do support up to 16 of every controller other than Xbox on Windows and if you switch to Linux we are able to support the full 16 Xbox controllers.

[turtle]

Originally posted by austinp_valve:

We can't do this because windows.gaming.input doesn't work in the background. We've spoken to the Microsoft input team about this both over email and in person, but to no avail.
We can support up to 16 Xbox controllers over directinput but that doesn't allow us to rumble or use the triggers at the same time so this isn't enabled in Steam. If you're interested in technical details there is a thread on the SDL2 forums where Slouken talks about this in more detail. I know that someone had worked on a pull request where they would switch input apis based on the number of controllers attached but last time I checked it was not yet stable enough to merge.

We do support up to 16 of every controller other than Xbox on Windows and if you switch to Linux we are able to support the full 16 Xbox controllers.

Appreciate the response! That limitation seems like a large oversight on Microsofts part, but maybe an intentional one? I'm not sure how coupled the nature of windows.gaming.input was but I could see Microsoft wanting to restrict input to only focused UWP applications. Still, being as this is the successor to xinput I'm sure Microsoft is looking at this being as flexible as possible, at least somewhere down the road...

I'm guessing this is the thread you referenced, it's an interesting read:
https://discourse.libsdl.org/t/supporting-more-than-4-xinput-capable-devices-on-windows-rfc/25666/24

It does sound like Jimbly has something working and tested, has this been merged into the main SDL repo?
https://github.com/Jimbly/SDL

I imagine you guys also might be using your own fork of SDL but I would implore you to look into integrating his changes. It would resolve a lot of headaches/workarounds people are using to get 4+ input games working on Windows.

[supersmo]

@austinp_valve
I wrote on stackoverflow a long time ago about Windows.Gaming.Input and wrote that I thought it couldn't access the controllers in the background.
Someone responded with a comment that they got it to work in the background but I never followed up on it.

Could be interesting to check out:
https://stackoverflow.com/questions/48748313/using-directinput-with-xbox-one-controller-and-window-focus-on-windows-10/54438707#54438707

This was the comment:
"Written native windows app with WinRT APIs loaded at runtime (using LoadLibrary and GetProcAddress) and Windows.Gaming.Input class usage. Seems working fine with vibration while window is not focused and no issues. – DJm00n"

[NeXuS23]

Xinput:
- Legacy and actually for Xbox 360 Controllers
- Only supports up to 4 controllers connected at any time
- Unable to use the extra rumble motors in XBox One controllers
- Controllers can be accessed in background (Global focus)

DirectInput:
- Legacy and for any controller
- Supports any number of controllers connected at any time
- No rumble on Xbox360 and Xbox One Controllers
- Input Axis issues with Xbox360 and Xbox One controllers (needs ingame fix)
- No guide button
- Can't be used with Windows Store Apps
- XBox One controllers cannot be accessed in background (Bug?)

Raw Input(Bypass DirectInput):
- Supports any number of controllers connected at any time
- No rumble on Xbox360 and Xbox One controllers
- Input Axis issues with Xbox360 and Xbox One controllers (needs ingame fix)
- No guide button
- Controllers can be accessed in background (Global focus)

Windows.Gaming.Input
- Supports any number of controllers connected at any time
- Only available on UWP devices (Windows 10, Xbones etc.)
- Gamepad class only supports certified Xbox One or Xbox 360 compatible controllers
- Non X Controllers supported via RawGameController class
- Controllers can’t be accessed in the background (No global focus? Only on UWP apps?)

Misc:
- The old Microsoft Xbox360 Wireless Adapter only supports up to 4 controllers connected at any time
- The new Microsoft Xbox Wireless Adapter for Xbox One Controllers supports up to 8 controllers connected at any time
- Bluetooth Receivers only support up to 7 controllers connected at any time.
- XInput and DirectInput can be mixed to override limits, but leads to new issues with registering and deregistering controllers

[turtle]

Originally posted by austinp_valve:

We can't do this because windows.gaming.input doesn't work in the background. We've spoken to the Microsoft input team about this both over email and in person, but to no avail.
We can support up to 16 Xbox controllers over directinput but that doesn't allow us to rumble or use the triggers at the same time so this isn't enabled in Steam. If you're interested in technical details there is a thread on the SDL2 forums where Slouken talks about this in more detail. I know that someone had worked on a pull request where they would switch input apis based on the number of controllers attached but last time I checked it was not yet stable enough to merge.

We do support up to 16 of every controller other than Xbox on Windows and if you switch to Linux we are able to support the full 16 Xbox controllers.

I think maybe the bigger question is what makes it necessary for an app to receive input while it does not have focus? Is it something related to Big Picture Mode? Why does steam input need to be able to receive inputs while out of focus? Is there no reason we can't "hot swap" input api's for these necessary features when it is necessary?

Thanks

[supersmo]

When a game is being played the game is in focus so in order for Steam Input to do its remapping magic it needs to receive the controller input while in the background.

[austinp_valve]

Yes, like supersmo said - Steam Input runs inside Steam's process rather than the game's which is why things need to work in the background. Steam reads the controllers, decides which mapping to apply based on which game or app has focus, then sends the output to the overlay. If a game is using Steam Input API then the game does call functions to poll the controller data, but the game side is just grabbing the processed action data out of a pipe rather than directly polling HW devices. Changing that is something we could look at in the future but it's a ton of plumbing work and it'd also have to play nice with the existing system that would need to continue to handle BPM, BPM overlay, and desktop input.

[austinp_valve]

There's an SDL change that we are shipping in the next beta cycle that will hopefully be able to gracefully fall back to Dinput when more than 4 controllers.

[turtle]

Originally posted by austinp_valve:

There's an SDL change that we are shipping in the next beta cycle that will hopefully be able to gracefully fall back to Dinput when more than 4 controllers.

That's awesome news! Thanks so much.