kisak-valve
commented
3 years ago Hello @ivyl, what version of Proton were you testing with? Is there a behavior difference between Proton 5.0 and older versus Proton 5.13 and newer?
Open ivyl opened 3 years ago
kisak-valve
commented
3 years ago Hello @ivyl, what version of Proton were you testing with? Is there a behavior difference between Proton 5.0 and older versus Proton 5.13 and newer?
ivyl
commented
3 years ago @kisak-valve this was tested with 6.3-5 as I don't expect Proton to have a role in creation of Steam's virtual controller.
I've checked with 5.0-10 and the results are the same: Steam Input enabled = nothing works, no sight of the virtual controller device, Steam Input disabled = xbox controllers do work
austinp-valve
commented
3 years ago The official configuration for the game uses Steam Input API so the game is expected to be calling Steamworks SDK functions for controller input instead of polling Xinput/whatever other Windows APIs. Is there an issue with calling those functions in Steamworks? Or maybe there's a USB/gamepad related API the game checks before polling for controllers that only works when the virtual device is created?
kisak-valve
commented
3 years ago @ivyl, symptom 3 in https://github.com/ValveSoftware/Proton/issues/4967 is the likely explanation for this issue. Can you check if the Steam overlay is not working for you with this game?
ivyl
commented
3 years ago @austinp-valve thanks for clarifying. Is there any way I can check the configuration myself to see if a game is configured that way?
The game polls XInputGetState() every now and then to see if something was plugged in. Nothing that would explain this.
Looks like the game uses the now deprecated SteamContoller API, version 007 to be exact. With some extra logging in place it looks like GetConnectedControllers() (called alongside XInputGetState()) always returns 0 even though a controller is plugged in. I've checked the lsteamclient and the wrappers look correct to me.
The repeated calls to GetCurrentActionSet() and ActivateActionSet() for controller handle 0 are a bit weird, but I expect the game does something similar on Windows.
@kisak-valve Steam overlay also does not work for me. Why would this explain the problem with the controllers?
The ELF class errors are normal, as both 32 and 64 bit versions are being preloaded and only one matches the architecture of the process, so there's something else that's wrong. I'll look into that a bit later.
ivyl
commented
3 years ago I've tried to see how things work on Windows and what GetConnectedControllers() returns, but that's not very straightforward. Is there any way to log those calls?
I have found something though. The inputs seems to be coming from XInputGetState(), even though I have only a DualShock 4 connected and external xinput test program confirms that I get ERROR_DEVICE_NOT_CONNECTED for all 4 controllers.
The game calls XInputGetState(0, ...) and gets ERROR_SUCCESS. Stack traces also show that we end up in ERW memory area that's mapped just below xinput. It looks like Steam on Windows is doing xinput hooking even in this configuration?
kisak-valve
commented
3 years ago I've seen user feedback several times asserting that if the Steam overlay is disabled or broken, then Steam Input is also non-functional. ~That is being tracked at #7787.~
I don't have insight into the implementation details, but there's no point in in focusing on Steam Input until the snafu with the Steam Overlay is evaluated.
ivyl
commented
3 years ago Thanks. I'll look into why overlay doesn't work to see if that will resolve the problems with Steam Input.
ivyl
commented
3 years ago Looks like gameoverlayui process is not getting spawned only for this game.
So at least we know that gameoverlayrenderer.so is loaded and works.
I've tried to start gameoverlayui manually, with the correct parameters for the game, the controller starts working but there's still no overlay. I've replaced gameoverlayui with a script that logs all the execs to be sure it just doesn't crash, but it's not even invoked for that game (it logs correctly for other games).
gameoverlayui is also a direct child process of Steam, I don't know what triggers it to spawn though. @kisak-valve can you ask around about that? I am not sure where to look next.
ivyl
commented
3 years ago I've checked if it works with a few other 64bit OpenGL games (e.g. DOOM (2016)) and yes, it does.
The overlay on Linux seems to be handled solely on the Linux side (even for Proton) through gameoverlayrenderer.so. Disabling GameOverlayRenderer64.dll has no effect on overlay for the games that do work.
gameoverlayrenderer.so is loaded correctly for Digimon (as we can see in the log from the previous comment) and I see nothing that would explain the absence of gameoverlayui process.
Since this is handled purely on the Linux side through Steam's proprietary components this is about as far as I can go with all my Proton knowledge.
Road-Drum
commented
3 years ago something that I discovered while skimming my own Proton logs, I found out that apart from steam_api64.dll this game contains sdkencryptedappticket64.dll, both having a linker version 14.14. Just lucky that I found out that one of my games, Ni no Kuni II: Revenant Kingdom to have both steam_api64.dll and sdkencryptedappticket64.dll but with linker version 12.0.
Ni no Kuni II: Revenant Kingdom has overlay starts successfully and I decided to capture its Proton log with these Steam libraries successfully loaded:
86234.997:010c:0110:trace:loaddll:build_module Loaded L"Z:\\home\\heyya\\.steam\\debian-installation\\steamapps\\common\\Ni no Kuni II Revenant Kingdom\\Nino2.exe" at 0000000140000000: native
<-- trimmed some system32 DLL calls -->
86235.009:010c:0110:trace:loaddll:build_module Loaded L"Z:\\home\\heyya\\.steam\\debian-installation\\steamapps\\common\\Ni no Kuni II Revenant Kingdom\\steam_api64.dll" at 000000003B400000: native
86235.010:010c:0110:trace:loaddll:build_module Loaded L"Z:\\home\\heyya\\.steam\\debian-installation\\steamapps\\common\\Ni no Kuni II Revenant Kingdom\\sdkencryptedappticket64.dll" at 0000000180000000: native
86235.012:010c:0110:trace:loaddll:build_module Loaded L"Z:\\home\\heyya\\.steam\\debian-installation\\steamapps\\common\\Ni no Kuni II Revenant Kingdom\\PhysX3_x64.dll" at 0000000000740000: native
86235.018:010c:0110:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\WS2_32.dll" at 00007FBCFA290000: builtin
86235.018:010c:0110:trace:loaddll:build_module Loaded L"Z:\\home\\heyya\\.steam\\debian-installation\\steamapps\\common\\Ni no Kuni II Revenant Kingdom\\PhysX3Common_x64.dll" at 0000000000A60000: native
86235.018:010c:0110:trace:loaddll:build_module Loaded L"Z:\\home\\heyya\\.steam\\debian-installation\\steamapps\\common\\Ni no Kuni II Revenant Kingdom\\PhysX3CharacterKinematic_x64.dll" at 00000000009D0000: native
86235.019:010c:0110:trace:loaddll:build_module Loaded L"Z:\\home\\heyya\\.steam\\debian-installation\\steamapps\\common\\Ni no Kuni II Revenant Kingdom\\PhysX3Cooking_x64.dll" at 0000000000C40000: native
86235.021:010c:0110:trace:loaddll:build_module Loaded L"Z:\\home\\heyya\\.steam\\debian-installation\\steamapps\\common\\Ni no Kuni II Revenant Kingdom\\ApexFramework_x64.dll" at 0000000000CD0000: nativeNothing surprising. DLLs from the game directory loads successfully. I decided to compare this with Digimon Cyber Sleuth
45934.835:0114:0118:trace:loaddll:build_module Loaded L"Z:\\home\\heyya\\.steam\\debian-installation\\steamapps\\common\\Digimon Story Cyber Sleuth Complete Edition\\app_digister\\Digimon Story CS.exe" at 0000000140000000: native
<-- trimmed some system32 DLL calls -->
\\Digimon Story Cyber Sleuth Complete Edition\\app_digister\\steam_api64.dll" at 000000013B400000: native
<-- trimmed some system32 DLL calls -->
45934.916:0114:0118:trace:loaddll:build_module Loaded L"Z:\\home\\heyya\\.steam\\debian-installation\\steamapps\\common\\Digimon Story Cyber Sleuth Complete Edition\\app_digister\\freetype.dll" at 0000000180000000: native
<-- trimmed some system32 DLL calls except XINPUT1_3.dll. Probably crucial -->
45934.935:0114:0118:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\XINPUT1_3.dll" at 0000000253CC0000: builtin
45934.939:0114:0118:trace:loaddll:build_module Loaded L"Z:\\home\\heyya\\.steam\\debian-installation\\steamapps\\common\\Digimon Story Cyber Sleuth Complete Edition\\app_digister\\cg.dll" at 000000006A000000: native
45934.941:0114:0118:trace:loaddll:build_module Loaded L"Z:\\home\\heyya\\.steam\\debian-installation\\steamapps\\common\\Digimon Story Cyber Sleuth Complete Edition\\app_digister\\cgGL.dll" at 0000000000660000: nativeI noticed that sdkencryptedappticket64.dll was never called for Digimon Cyber Sleuth. My knowledge on Steamworks and Proton is extremely limited but from its documentation it's another way of user verification and ownership like Session Tickets. Could this be the culprit? Unsure if this DLL is correctly loaded on Windows as there's no way to log like Proton
Your system information
Please describe your issue in as much detail as possible:
The game supports only xbox controllers and has Steam Input enabled by default. The controllers doesn't work until Steam Input is disabled.
Looking at Proton logs I've noticed that the real controller (DualShock 4 in this case, but I've also tried with xbox controllers) is being correctly ignored:
but there's no trace of Steam's virtual controller.
Indeed, Steam doesn't create the virtual controller for this game. There's no sign of it in both the dmesg and
/proc/bus/input/devices. I've tried few things like changing the controller mapping from the developer provided one to the Gamepad template (which is known to work) and trying to force enable Steam Input for the game (instead of just using the default) with no luck.I've then force-enabled Steam Input for Ori and the Blind Forest: Definitive Edition, and Steam Input works (sans the delay from bug #7868):
I would expect that we should see the same with Digimon, but we don't.
Steps for reproducing this issue: