Controllers stop working with some games if Generic Gamepad Configuration Support enabled

[magicmyth]

Previously I had a working Steam controller that adjusted as designed for each game. Turns out the issue started because I enabled Steam's Generic Gamepad Configuration Support. Disabling this feature allows the Steam Controller and my Xeox Pro Wireless controller to function in all games. On Ubuntu 16.04 and testing Rocket League the controllers continue to function with the Gamepad Configuration enabled.

Original post

Firstly sorry I did not report this bit earlier. It did not work quite out of the box as /dev/uinput was not having correct ACL set. I fixed this by renaming 99-steam-controller-perms.rules to 60-steam-controller-perms.rules. I picked up somewhere on the inter-webs at some point that some changes in udev rule processing had adjusted where the processing of devices tagged uaccess was done and thus the steam controller rules needed to be defined sooner. So it might be worth updating the steam package to do that.

Anyway I have confirmed that my user has access to write to uinput:

$ getfacl /dev/uinput 
getfacl: Removing leading '/' from absolute path names
# file: dev/uinput
# owner: root
# group: root
user::rw-
user:magicmyth:rw-
group::rw-
mask::rw-
other::rw-

To make sure I also sudo chmod 666 /dev/uinput but this had no affect.

On launching Steam the controller will act in its desktop mode when Steam is in desktop mode and when in Big Picture it still works as expected. It is when I launch a game that input stops working.

I've tested SC-Controller and it works just fine there. I also disabled all Solus Steam Linux integration to no affect and I opted into the Steam beta to see if changes there made a difference but unfortunately not.

I tested an older unstable test build (linux-steam-integration-0.5-18-1-x86_64.eopkg) which had worked previously with the controller (at least as I recall over the Steam Link) to no avail. So it seems to be somewhere else in the recent updates.

I've attached the output of Steam with Solus integration enabled and LSI_DEBUG on. steam-controller.log

That output is me simply starting Steam and launching Super Meat Boy which should switch the controller to standard gamepad mode. Looking at the logs Steam seems to think it is doing just that as it outputs Controller 0 Gamepad With Camera Controls uses xinput : true and with my past experience if it was the normal uinput write access issue it would mention the write issue but that is not happening here.

Note that message ioctl (SFEATURE): Broken pipe does not appear when I have LSI switched off.

[magicmyth]

Discovered that Steam has no issue setting any keyboard bindings on the controller. Its only if a button or axis is set to act as a normal gamepad input that they fail. Any input on the controller that is configured to behave like a mouse or key will function correctly.

[magicmyth]

I did a big eopkg roll back to the state my system was in on 2017-11-04 to see if I could find a update that may have caused this issue but its made no change. I've tested some more games and found that the controller works just fine as a gamepad with some games but not others. So far my list looks like:

Broken on:

• Shadow of Mordor
• Grid Autosport
• Dirt Rally
• Super Meat Boy
• Rocket League
• OWl Boy
• F1 2015

Works with:

• Speed Runner
• Dirt Showdown
• Sky Force
• Hollow Knight
• Dust: An Elysian Tail
• Borderlands 2
• Neon Drive
• Pac-Man 256
• BLazeRush
• Portal 2
• Spec Ops: The Line

Seems any Feral game (but not limited to) has stopped working with my controller unless I use SC Controller to force it into XBOX360/XInput mode, in which case it will work with those games.

Interestingly on the Feral racing games I have it configured so that rotating the pad outputs the left sticks movement so I can use it like a racing wheel, and I have it give haptic feedback as you rotate the pad. This feedback works still indicating the pad is in the right mode but the games just do not seem to receive any input.

This may not be an LSI issue but so far my Ubuntu machine still works correctly so its my best guess atm. It is very surprising to me that the package rollbacks did not fix the issue.

[magicmyth]

Ah ha! Found the culprit. It seems when you enable Generic Gamepad Configuration Support in Steam it breaks the Steam controller in the mentioned games 🤦 I don't think this is a Solus specific issue but I'll confirm that later on another machine. If that is the case I'll raise the issue with Valve (they won't be able to say "ug.. Solus is not a supported OS.. ug" then).

Note that with that feature enabled not only does the Steam Controller stop working but any generic gamepad. Worth noting in case some others run into this issue.

[magicmyth]

I've now tested Rocket League on another machine with Ubuntu 16.04 and it functions correctly with Generic Gamepad Configuration Support enabled. I've updated the issue description based on my findings.

[ikeydoherty]

Sooo I don't quite get where the issue is here? Is this just "Generic Gamepad Configuration Support" make things go borky? I'd love to know what that actually means so I know what to unbugger..

[magicmyth]

Quick answer: Yes it is “Generic Gamepad Configuration Support” that makes “things go borky" :)

Expanded: If (Steam desktop interface) you go Settings > Controller > General Controller Settings and check “Generic Gamepad Configuration Support” it allows non-Steam controllers (e.g. cheap generic DInput gamepads) to have custom bindings just like the Steam controller. Unfortunately when enabled any bindings that are mapped to a normal gamepad button (or simply the buttons have their default mapping) will no longer function in certain games. If those buttons are bound to the keyboard inputs (e.g. button 2 outputs F on the keyboard) it will correctly output the expected key's event.

One hunch of mine is it has something to do with xinput (or the xpad module). I'm quite sure that when Generic Gamepad Configuration Support is enabled then the controller is made to emulate a xinput device where as by default Steam simply outputs a SDL controller mapping environment. After all some games do not functioning correctly with a gamepad at all if they are not exposing xinput (which to me is insane on Linux). Before that option was there, there was another option which I think was simply xinput emulation for generic gamepad.

I know Steam OS has a patched version of xpad but last I knew Ubuntu was not using them but maybe they do now? Might be worth having a look at how Solus' xpad compares to Ubuntu's?

[ikeydoherty]

Probably worth us taking the xpad patches regardless. Maybe something is amiss with our xinput too..

[rkfg]

Thank you for reporting this! It was a frustrating issue here on Debian as well, most of the games worked fine but some just didn't and I couldn't find why. While looking for possible culprits I discovered that it's libSDL2's "fault" because it only happened in games that link dynamically to SDL2. I had a good test case with SteamWorld Dig (that works fine with a controller) and SteamWorld Dig 2 (that doesn't recognize it). Both games use their own in-house engine and the only big difference I saw in ldd is that the latter requires libSDL2.

If a game uses the host system libSDL2, the controller won't work. It seems that Steam runtime is not used anymore for about a year now, it's merely a fallback so if you have libSDL2 installed (and most certainly everyone does) it's used. So then I found STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 env var and it really fixed the bug now that the games used Steam runtime's libraries (and they contain SDL 2.0.5, Debian is on 2.0.7 and 2.0.8, testing/stable as of now). So I thought it's a regression in SDL, somewhere between 2.0.5 and 2.0.7, though downgrading it in the host system didn't help. Messed a bit with gamecontrollerdb but to no avail.

I checked the library paths it in /proc//maps. But accidentally I found this report in Google and it was really it, after disabling the said "feature" I no longer need any hacks and overrides, so thanks again! I must've enabled it out of curiosity long ago and didn't pay much attention to it because what could possibly go wrong? Most of the games worked as they did before and I don't have a "generic controller", only XBox360 and Steam Controller so this doesn't apply, right? Apparently, wrong.

[michaeltintiuc]

I can confirm this, although the issue was with the Xbox setting, but I can't seem to get the controller working in "Big Picture" mode, it just says no controllers detected, I'm unsure if it's the same issue or related to it.

[Whaym]

Confirming that this is still happening on Mint 19. (And thank you for describing the issue in so much detail, I hadn't even realized that was why my controllers weren't working)

[JuicyPaperclip]

THIS FINALLY FIXED IT FOR ME! https://steamcommunity.com/groups/SteamClientBeta/discussions/1/144512526679509498/