Hello @lhindir, I think that heaping a bunch of dissimilar games together for this isn't going to be productive. Each game can be using a different subsystem for their controller handling and this is too general a topic to handle in this manner.
It would be better to add a note with your findings to the compatibility report of each game that is misbehaving so that the feedback can be tracked properly on a per-game basis. If there isn't already a compatibility report for some of these games you tested, then please open a new compatibility report for those games.
Additionally, issues with controller support in native games should be mentioned to the game's dev(s), and if there's a difference in behavior between running a native linux game inside and outside the Steam Linux Runtime container environment, then please open an issue for that in the steam-runtime issue tracker.
Alright, thanks. I thought this might result in less noise since a good number of games seem to break in the same ways due to their shared subsystems, but I can do that.
I have a similar point of view from the Steam Runtime's perspective.
If there is an actionable bug that affects multiple games and can be fixed by Proton or Steam Runtime developers, we can easily "merge" duplicate bugs after fixing it, by closing the "duplicates"; but it's difficult and time-consuming to disentangle a single bug number that has been used to represent multiple root causes. Proton and the Steam Runtime have a lot more users than developers, so please help us to spend our limited time on fixing bugs rather than digging through large issue reports :-)
In general, I would prefer not to receive bug reports for the Steam Runtime that cannot be fixed by the Steam Runtime - those just clutter up the issue tracker and distract developers. I suspect Proton developers have a similar preference. For instance, if a particular game only supports 4 simultaneous players with controllers, then the Steam Runtime is unlikely to be able to change that: adding more players would likely require changes in the game's engine or middleware libraries, or the game itself.
I'd also prefer to avoid having an issue report that we can never close. If the scope of an issue is "game controller support is not perfect in all games", then, realistically, we are never going to be able to close that, because there will be at least one game with a problem - and even if that's something we can fix, people will discover a different problem in a different game by the time we've fixed the first game, and so on. After a while the number of comments will become unmanageable and we won't be able to find relevant information any more.
Proton's main goal is to try to behave like Windows: if a game has limitations on Windows (no more than 4 controllers? only supports Xbox controllers? etc.) and those limitations are replicated by Proton, then Proton has done its job. In some cases Proton might "accidentally" avoid game limitations (for example the game might sometimes think a Playstation controller is really an Xbox controller, which might mean it works even though the game only supports Xbox controllers), and if that happens, it's a bonus; but it isn't really part of the goal. Better controller support for Windows games in that situation would start with the developer fixing those limitations on Windows.
Similarly, the Steam Runtime's goal, where input devices are concerned, is to pass through the hardware from the host system. There are some technical reasons why we can't necessarily always do that perfectly (if games are directly using libudev, it isn't possible to replicate that in the container, so ideally games should be using higher-level APIs like SDL), but if a native Linux game has limitations when not running in a container, we're certainly not going to be able to solve those limitations in a container.
One exception to this is that if a game developer (or a game engine developer) comes to the Steam Runtime issue tracker and says "we want to support more than 4 controllers, but..." and gives us technical details of why they think the Steam Runtime is the layer that's preventing them from doing so, then that is something we can try to fix in the Steam Runtime.
Additionally, issues with controller support in native games should be mentioned to the game's dev(s), and if there's a difference in behavior between running a native linux game inside and outside the Steam Linux Runtime container environment, then please open an issue for that in the steam-runtime issue tracker.
In general, I would prefer not to receive bug reports for the Steam Runtime that cannot be fixed by the Steam Runtime - those just clutter up the issue tracker and distract developers. I suspect Proton developers have a similar preference. For instance, if a particular game only supports 4 simultaneous players with controllers, then the Steam Runtime is unlikely to be able to change that: adding more players would likely require changes in the game's engine or middleware libraries, or the game itself.
Proton's main goal is to try to behave like Windows: if a game has limitations on Windows (no more than 4 controllers? only supports Xbox controllers? etc.) and those limitations are replicated by Proton, then Proton has done its job. In some cases Proton might "accidentally" avoid game limitations (for example the game might sometimes think a Playstation controller is really an Xbox controller, which might mean it works even though the game only supports Xbox controllers), and if that happens, it's a bonus; but it isn't really part of the goal. Better controller support for Windows games in that situation would start with the developer fixing those limitations on Windows.
Similarly, the Steam Runtime's goal, where input devices are concerned, is to pass through the hardware from the host system. There are some technical reasons why we can't necessarily always do that perfectly (if games are directly using libudev, it isn't possible to replicate that in the container, so ideally games should be using higher-level APIs like SDL), but if a native Linux game has limitations when not running in a container, we're certainly not going to be able to solve those limitations in a container.
Of course, I wouldn't submit issues for games not apparently due to Proton or the runtime, sorry if this wasn't clear. I'm aware that compatibility layers by definition shouldn't be expected to fix intrinsic limitations of the platform they're reproducing, much less bad software running on top of the layer. FWIW I did verify the games in the table above do support >4 controllers.
If there is an actionable bug that affects multiple games and can be fixed by Proton or Steam Runtime developers, we can easily "merge" duplicate bugs after fixing it, by closing the "duplicates"; but it's difficult and time-consuming to disentangle a single bug number that has been used to represent multiple root causes. Proton and the Steam Runtime have a lot more users than developers, so please help us to spend our limited time on fixing bugs rather than digging through large issue reports :-)
I'd also prefer to avoid having an issue report that we can never close. If the scope of an issue is "game controller support is not perfect in all games", then, realistically, we are never going to be able to close that, because there will be at least one game with a problem - and even if that's something we can fix, people will discover a different problem in a different game by the time we've fixed the first game, and so on. After a while the number of comments will become unmanageable and we won't be able to find relevant information any more.
These make a lot of sense, thanks for taking the time to explain!
proton experimentalx1 2021-03
Overview
I have quite a few local multiplayer games and Proton has always been hit-or-miss with them. In 5.13 it seems hotplugging works for quite a few games now, so I went through some games and documented controller issues. These issues are pretty serious for local-multiplayer-focused games, since you essentially need great controller support to have a good experience with a couch game. These games are not hugely popular, but it seems Valve is expending some effort on Remote Play and Linux compatibility, and fixing these controller issues could significantly improve first impressions of Steam and Proton for couch gaming enthusiasts.
Data
The tables below were compiled using four Steam Controllers, an Xbox One controller connected via the new dongle and xow, and a PS4 controller. I do not have Steam Input configuration support enabled for the Xbox and PS4 controllers. If a game worked with neither the Xbox nor the PS4 controller, I could not test for >4 player support.
HPstands for hotplugging.According to @ivyl there is a Mono fix that will improve Xbox controller support for Duck Game, and a fix coming to Proton Experimental that will improve Xbox controller detection across multiple games. If you're aware of other upstream issues affecting the listed games, please let me know so I can include them here.
Conclusion
I'm a big fan of local multiplayer gaming on Linux, so it's great to see the progress in the last few years. I have quite a few more games I can test, and I can also test the Steam Input support for Xbox and PlayStation controllers. @smcv, I could also post a similar issue to steam-runtime-tools for native games, if you like. I just stopped after a few games in case this isn't helpful.
Please let me know if I can provide any more info that's of any use or if there's a better place or format for this issue. Thanks.