icculus / ControllerImage

A library for producing images of SDL controllers.
zlib License
107 stars 2 forks source link

Steam Deck controller requires manual management #32

Open ShockSlayer opened 1 month ago

ShockSlayer commented 1 month ago

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 a standard controller, meaning this library could only detect and load Steam Deck glyphs via GUID. Currently, there is no guids file in the steamdeck 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.

icculus commented 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?

slouken commented 1 month ago

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

icculus commented 1 month ago

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!

ShockSlayer commented 1 month ago

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.

icculus commented 1 month ago

Did you update the art database? It needed a small update too. I forgot to mention that.

ShockSlayer commented 1 month ago

Yeah, I added in the guids file for the steamdeck and rebuilt it. That was the only change I saw.

icculus commented 1 month ago

Okay, I'll take a closer look over here, sorry about that!

ShockSlayer commented 1 month ago

image 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.