Open ShockSlayer opened 1 month ago
Hey @slouken, is there a correct way to decide you're using the Steam Deck's on-device controller from SDL3, even when Steam Input is involved?
The latest version of SDL will provide the correct name and VID/PID of the controller, and you can check that to see if it's the Steam Deck controller, which uses 0x28de/0x1205
Okay, @ShockSlayer, I haven't actually tested this on a Steam Deck, but if you get the latest in revision control for both SDL3 and ControllerImage, it should be able to figure out you're on a Steam Deck controller in ControllerImage_CreateGamepadDevice() even when Steam Input is in the mix.
Let me know if it still doesn't work and I'll reopen this issue!
Took me a little bit to update my build of SDL3, but I've got that sorted and I've merged in these changes. At first glance, it doesn't appear to work, and still ends up creating the device from the string as an xbox360 controller.
Did you update the art database? It needed a small update too. I forgot to mention that.
Yeah, I added in the guids file for the steamdeck and rebuilt it. That was the only change I saw.
Okay, I'll take a closer look over here, sorry about that!
I figured I would also see if I could figure out what's going on; this is a screenshot from my application running on the Steam Deck, with a handful of prints. SDL is correctly detecting that it's on steam deck, via SDL_GetHintBoolean("SteamDeck", SDL_FALSE)
. After the result (which is just a temporary int placed in the function to let me know where it finally creates info
) I'm also printing the result of guidstr
and vidpidguid
. It looks like the values returned by SDL_GetGamepadInstanceVendor
and SDL_GetGamepadInstanceProduct
are that of the virtual controller still.
From here I wanted to check those functions more closely, but they're using internal stuff like SDL_GetJoystickInstanceVirtualGamepadInfo
which I can't call directly without modifying the library a bit. That said, my initial guess is that these functions can't be used to get the actual USB device data when the virtual gamepad is present.
I am guessing this is by design, since as I understand it, when properly booting games through Steam on the Steam Deck, the actual internal controller cannot be found by SDL, since Steam Input always hooks and hides it. From what I can tell, this cannot be disabled either (and that's probably for the best on Steam's part.) I am not far enough along in my own development to be acquainted with Steamworks, but I'm guessing that there are ways to determine what physical buttons are mapped to the virtual xbox360 controller, which could then be used to display the proper glyphs.
With that said; closing Steam in "Desktop mode" disables any Steam Input shenanigans, and running an application directly allows SDL to find and use the Steam Deck's internal controller. However, there's no
SDL_GamepadType
for this, so it just shows up as astandard
controller, meaning this library could only detect and load Steam Deck glyphs via GUID. Currently, there is noguids
file in thesteamdeck
folder, so this results in nothing being loaded.I'm not sure if there are any hardware revisions that would change this, but I did grab the GUID of my Steam Deck's internal controller, which is
0300efefde2800000512000011017200
. This could at least be added to the themes to solve this particular case, although in the grand scheme of "instant Steam Deck support" it leaves much to be desired.