Regression of Proton SDL input handling - SDL_GAMECONTROLLERCONFIG ignored

[Cat-Lady]

Hello Steam'ies,

1. There are games, that - sadly - doesn't support handling controllers via Steam Input (at least, if using Proton).
Example of such game: "EA Star Wars: Battlefront II" (1237950) - merely having Steam Input enabled in game's settings result in absolutely no input from controller registered in game, whatsoever.

Fortunatelly, in such games, it was always possible to simply disable steam input, and launch the game with SDL_GAMECONTROLLERCONFIG="". For example, I was putting such string as game's launch command:
SDL_GAMECONTROLLERCONFIG="03000000a30600006207000011010000,Saitek X52 Pro Flight Control System,a:b25,b:b7,x:b13,y:b26,back:b8,start:b9,leftshoulder:b23,rightshoulder:b24,dpup:b6,dpdown:b15,dpright:b30,leftx:a5,lefty:a2,rightx:a0,righty:a1,lefttrigger:b18,righttrigger:b0,platform:Linux," %command%

Such rebinding was properly picked up by Proton as SDL mapping, and changes to the string were reflected in what was assigned to controller functions expected as Xinput, by game.

2. At some - woefully, unspecified - time during last two weeks, this stopped working altogether. Each and every attempt to use previously working mapping, or inserting another one, gets totally ignored in the whole prefix.

Additional info:

a) I tried each and every way of providing that env variable - from mentioned above launch parameter, to setting it up before launching Steam itself, and having it as global, system-wide env variable.

b) I ensured that nothing overwrites the variable, inserting hooks that will output SDL_GAMECONTROLLERCONFIG value before starting steam/game, during its runtime, and just after leaving the game/closing Proton. In all cases, the value remained as I had it set.

c) I inserted Windows tools for checking Xinput mappings for buttons and axes into prefix, and tested running it via Steam/Linux Runtime/Proton combination, instead of actual game. The tools were confirming that Xinput mapping is completely ignoring the variable that I set, and was matching the unusable configuration as experienced in game.

d) Steam client - when run with said env variables set up before start or as global parameter - was properly grabbing this mapping, offering it as "default" when trying to remap controller via Steam Input tools. Obviously, this had no use in game that doesn't work with Steam Input, but was confirming that the mapping is grabbed by Steam pre-Proton run.

e) Of course, I also tried adding proper mapping to config.vdf of the Steam itself, but it was only replicating what I already tried with configuring the controller via Steam Input.

f) I even resorted to trying setting up:
HKEY_LOCAL_MACHINE -> Software -> System -> CurrentControlSet -> Services -> WineBus
...in-prefix registry values, namely:
Enable SDL 1/0
Map Controllers 1/0

In all combinations, with or without setting my mapping string as:
HKEY_LOCAL_MACHINE -> Software -> System -> CurrentControlSet -> Services -> WineBus -> Map - > <value>-<mapping string>

...all to absolutely no effect.

g)
At the same time, SDL_GAMECONTROLLERCONFIG is still grabbed properly by regular (non-Proton) wine prefixes, and affect what Xinput windows applications see as controls mapping.

---

The most strange thing about this issue, is that I am experiencing it on ALL versions of Proton now - including the ones where I had it working before - and on all easily available versions of the runtime, from previous_release to client_beta. Example of Proton version, where I had it working fine before, and it is not working now:
1612904805 proton-5.13-6
I also tried Proton Experimental, Proton 6.3.2, etc... All versions down to 5.0.

---

(Maybe) relevant logs:

Proton:
steam-1237950.log

Runtime:
I tried to grab runtime logs, but was unable to launch the game with logging due to:
ValveSoftware/steam-runtime#402
If the log is still of improtance, despite not reaching the point of game running (the lack of regard for remapping variable is affecting whole prefix, after all), the log from above bug report is the relevant one, used on the affected install and prefix.

System info:
systeminfo.log

---

I hope that a fix or way to untangle this riddle will be possible to be found, as I spent few days trying to debug the issue without success - the "random" default mapping game is picking up is completely unplayable.
In any case, I stand in to provide whatever testing and additional logs/info might be needed.

I am reporting this as general Proton issue, not game specific one - due to the fact that Xinput in the whole prefix seems to be the one that lost ability to be remapped, having not much to do with the game itself (apart from the woeful lack of supporting Steam Input, but it is unrelated).

[Cat-Lady]

By using a self-compiled Proton with the Proton SDL changes reverted, I am able to get the remap via SDL_GAMECONTROLLERCONFIG variable working again. So, it is definitely a regression of the SDL rewrite/gamepad additions.

[Cat-Lady]

I was able to work around the issue on official proton, by modifying in-prefix registry key as follow:
HKEY_LOCAL_MACHINE -> Software -> System -> CurrentControlSet -> Services -> WineBus
Set new dword:
DisableHidraw 1

This brings back ability to remap controller via the keymap, IF handling of said controller is disable in steam client globally. Per-game disable of steam input (override disable for game) doesn't seem to work.

[ivyl]

AFAIU the SDL mappings are an implementation detail and is not something that is guaranteed to continue working. They should work (may change in the future) for DirectInput and anything that is either real or faux xinput device.

The DisableHidraw toggle helping here is interesting. That suggest that your device (I assume we are talking about X52) has a hidraw node in /dev/ that is accessible by your user. Because of that the device goes through winebus_udev.c and is exposed as a HID device to the software on the other end. If the node was not readable it would go through winebus_sdl.c and would result in a faux xinput device.

Do you happen to know how this device work on Windows? My guess would be that X52 is a HID/RawInput device there as well and needs software mapping to xinput. This is quite common for HOTAS.

The mapping is something that Steam Input should handle but it seems to be broken, see ValveSoftware/steam-for-linux#7868

[Cat-Lady]

Thank you for valuable insight!
Yes, the device is having a /dev/hidraw0 device that is accessible by user (just checked). As for how it is working in windows, I have no idea, but evidence suggest that your assumption should be correct.

[nezd5553]

This issue seems to have reappeared in Proton 7.0. I have an SDL mapping for my Nintendo Switch Pro Controller as suggested by the Arch Linux wiki. It works on Proton 6.3-8c and vanilla Wine 7.2, but not on Proton 7.0-1c or Proton Experimental (experimental-7.0-20220310). I fixed it with a new DWORD DisableHidraw=1 at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\winebus.

[Apxdono]

There's definitely an issue with one of the gamepad patches starting from 7.0. I observed another version of the issue with DualSense PS5 controller where button mappings were incorrect. This controller, actually 2, work perfectly well with Steam and Lutris games. I also own a pair of DualShock PS4 controllers, they work fine too.

Details

I was trying to launch Mortal Kombat 11 via Lutris (Steam had some sort of issue during library migration and can't revalidate files, and I'm 2 lazy to dl once again). On lutris-7.1 and lutris-7.2 versions of wine the game did start, but it lacks some MK11 patches that improve performance. Controller mappings were fine.

As soon as I switched to any GloriousEggroll version of proton (any steam or lutris 7.x+ has this behavior as of writing), button mappings for PS5 controller became incorrect: X (A) swaps places with O (B) and □ (X) swaps with △ (Y) (Values in brackets are for X Box mapping). With same GE versions PS4 controller works flawlessly. Using DisableHidraw with 1 as value did resolve the issue.

Just sharing my experience here, mb it'll be of any use.

[StoffelCPR]

There seems to be an issue related with EA games. Not sure if this is tracked anywhere else but the overlay isn't working inside EA games due to an EA update and this in turn disables controller support.