SDL 2.30.4 breaks Steam Deck gamepad on Arch Linux

[sealedgo]

SDL 2.30.4 breaks Steam Deck gamepad on Arch Linux

[slouken]

@smcv, any ideas?

[smcv]

I don't have a Steam Deck, so I am not the right person to debug this.

The most relevant change in 2.30.4 is likely to be 361cae0, which fixes a known regression since 91f8b4d (between 2.28.x and the 2.29.1 prerelease), ValveSoftware/steam-for-linux#9571. My understanding of the regression is that when using Steam Input, Steam creates a virtual Xbox 360 controller (device ID 28de:11ff) corresponding to each physical controller that is being managed by Steam Input, and then instructs SDL and Proton (Steam's version of Wine) to ignore the physical controllers and read from the virtual controllers instead. Steam assigns controller names that encode the "slot" number, based on its UI for reordering controllers, and Proton parses the name to figure out how to assign the virtual controllers to the expected XInput slot.

This particularly matters for local multiplayer games that only support the 4 controllers in the first 4 XInput slots: if players have connected 4 external USB/Bluetooth gamepads (Xbox, Playstation, Switch) and do not want any player to be using the Deck's built-in gamepad, then they need to tell Steam to reorder the controllers so that the Deck's built-in gamepad is in slot 5 or later.

[smcv]

the Steam Deck gamepad

With SDL 2.30.3, were you using the physical gamepad device directly; or were you running Steam in the background and letting it map the gamepad to a Steam Input virtual gamepad, and then having KDE System Settings talk to that?

If you have Steam installed (it doesn't need to be running for this, only installed), then running its diagnostic tool is likely to be helpful:

~/.steam/root/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-input-monitor --once

This enumerates all the raw HID and evdev input devices that SDL could potentially access, together with the information that SDL would use to identify them. Run this in the same situation where you were trying to use game controllers in KDE System Settings and Wine, whatever that is (but please also clarify what that situation is!)

It might also be helpful to compile SDL 2's test/testgamecontroller.c and try running that, to compare SDL's view of the game controllers with the diagnostic tool's. In some distributions this is packaged into a separate installable package (for example in Debian/Ubuntu, it can be found in /usr/libexec/installed-tests/SDL2 if you install the libsdl2-tests package) but I think in Arch you would have to compile it yourself.

Wine is very complicated, and I don't know what patches (if any) Lutris applies to it, so it would be better to eliminate Wine from consideration to start with, and get the controller working with native Linux software first.

[sealedgo]

With SDL 2.30.3, were you using the physical gamepad device directly; or were you running Steam in the background and letting it map the gamepad to a Steam Input virtual gamepad, and then having KDE System Settings talk to that?

Using the physical gamepad device directly, I don't have Steam running in the background and don't have the Steam runtime initialized, though I do have the steam package installed for the udev rules. I notice this difference in KDE System Settings depending on SDL version:

With SDL 2.30.3:

Device: Steam Deck (0003:0002:02)

With SDL 2.30.4:

Device: Steam Deck (/dev/input/event11)

[smcv]

This could perhaps indicate that 2.30.3 as provided by Arch is accessing the device via raw HID, and 2.30.4 is accessing it via evdev?

[smcv]

If it's that, then 793a068 might be another commit to look at.

[slouken]

Can you build SDL3 and check what the output of testcontroller is? Switching from USB to hidraw shouldn't prevent the controller from working.

[slouken]

Actually, since this is SDL2, using test/testgamecontroller from 2.30.4 is probably an easier way to verify using the system installed SDL.

[sealedgo]

test/testgamecontroller output built from and using SDL 2.30.4:
2.30.4.log

test/testgamecontroller output built from and using SDL 2.30.3:
2.30.3.log

[slouken]

Oh, the USB driver is not used by default to prevent applications locking exclusive access to USB devices. If you want to override that behavior, try setting the environment variable SDL_HIDAPI_LIBUSB_WHITELIST=0

[sealedgo]

Overriding the behaviour with that environment variable does make the Steam Deck gamepad work again on SDL 2.30.4, which resolves the issue for me. Thanks. I'm unsure if this means the issue can be closed or if it is preferred to be left open.

[slouken]

Okay, it sounds like it's working as intended. Thanks!