ValveSoftware / ValveSoftware/Proton
Regression of Proton SDL input handling - SDL_GAMECONTROLLERCONFIG ignored
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 32.8k
- Forks
- 1.6k
- PR merge metrics
- PR metrics pending
Description
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:
https://github.com/ValveSoftware/steam-runtime/issues/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).
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the SDL_GAMECONTROLLERCONFIG behavior across the Proton versions listed in the report and compare the attached steam-1237950.log and systeminfo.log. Trace how the variable reaches Xinput in Proton versus a regular Wine prefix; done means the supplied mapping is honored again throughout the affected prefix.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, linux
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100