Externals: Update SDL to 2.30.6

[khg8m3r]

Attempting to fix 3rd party switch pro gyro issues reported on the forums.
Also a bunch of other fixes, notably one being Steam Deck SDL support for the extra buttons.
SLD claimed that 2.28 was their last release, but they made some changes since then, so instead of pulling the tagged release I pulled the latest sdl2 branch updates

[SuperSamus]

Note that since SDL 2.26.5, macOS minimum target is raised to 10.11.
https://github.com/libsdl-org/SDL/releases/tag/release-2.26.5

[Pokechu22]

libsdl-org/SDL@f032e8c isn't a tagged release (as you say). Although it's probably OK to update to it, especially if the update doesn't require dolphin changes so linux package maintainers can use an older version that they already have packaged, it's probably not a good idea to refer to it as 2.29.0; instead I'd refer to it as a 2.29 development version. That way when an actual 2.29.0 releases it's more clear that we were using something else. (Unless SDL exclusively uses odd-numbered versions for development versions, which might be the case looking at their releases page; I'm not super familiar with it.)

[khg8m3r]

@SuperSamus Dolphin's minimum macOS target is 10.15, so it should be fine? Looks like the osx buildbot failed because there's a version check that's hardcoded. I'll look into that real quick

[khg8m3r]

@Pokechu22 According to their pull request: libsdl-org/SDL@ceece91, they're calling it 2.29.0 for development. I could rename this to point out this is a snapshot before the official 2.29 release, but since they're in maintenance mode now since 2.28.0, this is more of a stopgap before Dolphin moves to SDL3 (or uses sdl2-compat)

[Pokechu22]

Ah, looking at how they handle things, 2.28.0 RC1 is actually prerelease-2.27.1 and there is no build tagged 2.27.0. So based on that calling it 2.29.0 is probably fine.

[SuperSamus]

Reminder that SDL 2.28 is still being updated. 2.28.5 is the latest release.

[khg8m3r]

Looking for some input on what to do. Should I go down to 2.28.5 point release, bump up to the latest 2.29.0 release, or wait until the 2.30.0 milestone is completed?

Option 1 might not fix all the joycon/Steam Deck issues I was trying to fix with this pull request, would need to investigate.
Options 1 and 2 will run into the LTEK dance pad issue until it's fixed in the rolling release leading up to 2.30.0.
Option 2 might run into an issue with the GC adapters in PC mode. Would need to look into it based on libsdl-org/SDL#8617
Option 3 will mean waiting until who knows when, they're already past the deadline

[dreamsyntax]

@khg8m3r The LTEK issue (which probably affects other devices as well) might* be resolved in SDL commit cc20d01 per: libsdl-org/SDL#8662 (comment)

I think it would be worth testing this commit in this branch (or another), and if they backport it to 2.28.x, then I don't see an issue with going with that. I would prefer not to lose device support.

That said, since Dolphin has other options besides SDL its not like its impossible to use the devices affected anyway, so its not necessarily a full blocker.

[dreamsyntax]

Update: The SDL commit cc20d01 is confirmed to fix the issue for PCSX2. It currently lives in the SDL2 branch, not sure if its strictly planned for 2.30 or will be backported yet.

[dreamsyntax]

SDL member came back with

2.30.0 is the next SDL release, and we're wrapping things up for a release next month.

I would prefer we wait for 2.30, but again its not a total blocker if there's a critical feature you want in sooner than Jan 30.

[khg8m3r]

SDL member came back with

2.30.0 is the next SDL release, and we're wrapping things up for a release next month.

I would prefer we wait for 2.30, but again its not a total blocker if there's a critical feature you want in sooner than Jan 30.

Well this PR has already waited this long, might as well wait for the 2.30.0 release so that it can be synced up to a point release instead of an arbitrary SDL commit.

It's good to know the LTEK issue is fixed, I'd like to not have any regressions

[SuperSamus]

https://github.com/libsdl-org/SDL/releases/tag/release-2.30.0

[dreamsyntax]

2.30.0 is indeed out now.
Once this is integrated in this branch I'll verify LTEK

[SuperSamus]

https://github.com/libsdl-org/SDL/releases/tag/release-2.30.1

[khg8m3r]

Looks like 2.30.1 fixes a crash for controllers on macOS, so I'll probably pull to that release, thanks to @SuperSamus for pointing that out.

Been absolutely slammed with work and some personal stuff, should finally have some time this week to get this updated and pushed for review.

[SuperSamus]

https://github.com/libsdl-org/SDL/releases/tag/release-2.30.2

[dreamsyntax]

Any chance this can be worked on soon? I have a planned feature dependent on it

Also, 2.30.3 just came out.

If you are too busy with other obligations I wouldn't mind taking it over as well.

[khg8m3r]

@dreamsyntax I've been on a bunch of back-to-back work trips but I get back tomorrow. I'll get this updated and pushed tomorrow night or Saturday morning 👍

[AdmiralCurtiss]

This still fails to build on most of our builders...

[khg8m3r]

@AdmiralCurtiss yeah, I was poking this the other day with @dreamsyntax, gotta do some deeper debugging on why the default SDL 2.30.3 release commit doesn't want to build. Might need to do either a patch in Dolphin or see if the SDL repo has the fixes but they haven't pushed to a point release yet.

[Peter0x44]

A release has since been tagged:
https://github.com/libsdl-org/SDL/releases/tag/release-2.30.5

[dreamsyntax]

Is this going to be addressed? I understand schedules and all that, but its been a year...
If you don't have time it may be better to just close and let someone else grab it.

[khg8m3r]

@dreamsyntax from our discord discussion, I think everything is pushed now to solve the compiler problems I was seeing on Windows and Linux. If we can figure out he buildbot issues I think this should be done

[Peter0x44]

Not to be annoying but there's another release since
https://github.com/libsdl-org/SDL/releases/tag/release-2.30.6

[khg8m3r]

Oh no! I'll get that added since it fixes a controller crash

[dreamsyntax]

Not sure what to do about the builder situation other than 'whatever' power through it. At this point all the different builders do pass. It's just a matter of the cache.

Planning to test this still, just a bit busy.

• Steam Controller
• Dual Sense
• Logitech F310
• LTEK Dance Pad
• Xbox (One/Series HWID)

[Peter0x44]

I can test the Google Stadia.

[dreamsyntax]

Tested on Windows 11, 23H2, verifying all buttons, axis, vibration, gyro/other sensor functions:
Steam Controller ❌ (also does not work in master, so not a blocker)
Dual Sense ✅
Logitech F310 ✅
L-TEK Dance Pad PRO ✅
Xbox (One/Series HWID) ✅

[Peter0x44]

Tested on Windows 10 2022h2 19045.4651 with the google stadia controller, all axes, triggers, buttons, rumble function correctly.

[dreamsyntax]

Tested on Android 14
Dual Sense ✅
Logitech F310 ✅

As Device "Android/1/(name)"
I stopped here as I don't think SDL has any relation to Android version, but verified the two worked above as expected anyway.

[dreamsyntax]

Tested on Linux (Linux Mint Debian Edition 6 - LMDE Faye):
Steam Controller ✅
Dual Sense ✅
Logitech F310 ✅
L-TEK Dance Pad PRO ✅
Xbox (One/Series HWID) ✅ - Had some weirdness where unplugging other devices led to it registering as SDL0,SDL1, and SDL2 all at once. I am able to reproduce this happening on master, so unrelated to PR.

As a side note, I noticed Gyro does not appear like it does on Windows for Dual Sense. However, this also happens on the flatpak on Debian. When running the flatpak on Arch, then Gyro works as expected, so probably distro specific.

Note to reproduce Xbox issue on Linux:

1. Have Dolphin open and open the Vibration sub-menu.
2. Plug in an Xbox controller - notice the LED does not come on
3. The device will appear in the list as SDL0, but inputs will not work. Close and open the vibration sub menu. Each time this is done it will register as SDL1, SDL2, SDL3 etc...
4. Close Dolphin, unplug the Xbox controller, re-plugin the Xbox controller. Note the LED should be working now.
5. Re-open Dolphin, device now properly work as SDL0 only.

[dreamsyntax]

Tested on macOS Sonoma 14.6.1 / Apple M
DualSense ✅ - working as expected, including gyro/accel
No luck with the other controllers but I didn't install drivers for them.

[AdmiralCurtiss]

Well, let's hope this doesn't break the build system, I guess...

[OatmealDome]

It looks like this SDL update is causing some issues on the Steam Deck. The Steam Virtual Gamepad device is no longer showing up.

Issue report: https://bugs.dolphin-emu.org/issues/13612

[dreamsyntax]

Is this confirmed? I noticed SDL renamed some devices, so it may just be a case of users needing to re-select their controller from the device drop down.

Ill ask someone with a steamdeck to check.

[ds22x]

I can confirm the Steam Deck Controller in the device drop down is exclusively used by the built-in Steam Deck controls, meaning you'd have to switch device whenever you want to use an external controller through SDL.

[dreamsyntax]

I had someone with a SteamDeck verify.
It was as I suspected the device was just renamed. It is not broken.

Nevermind. Theres weird stuff depending on Desktop Mode vs Game Mode.

These can change depending on the mode.

Desktop Mode has:
SDL/0/Steam Deck
SDL/0/Steam Virtual Gamepad

Game Mode has:
SDL/0/Steam Deck Controller

[khg8m3r]

Well that certainly is an odd issue. I recently installed a new SSD in my Deck and did a fresh OS load, I'll see if I can poke at it and find what files changed was on SDL that caused this.

[ds22x]

I'd like to add that SDL/0/Steam Virtual Gamepad is controller agnostic
As in, it's mapped to whichever controller assigned to port 1 in Steam Input, whereas something like SDL/0/Steam Deck Controller definitely isn't, and therefor you'd need to each time manually change the device to, as an example, something like SDL/0/DualShock Wireless Controller or SDL/0/XBox One S Controller everytime you want to use an external controller on the Steam Deck.

The evdev equivalent for Steam Input, evdev/0/Microsoft X-Box 360 Pad 0 through 3 for ports 1 to 4, still function as the Steam Virtual Gamepad used to before the update.

[SuperSamus]

One thing to note for regular Linux is that before, the device name depended on whether Steam was open or not, which was very annoying.
Now, my SDL/0/Nintendo Switch Pro Controller will work regardless if Steam is open or not, which to me is an improvement.
(I'm speculating that these are related, I'm not 100% sure.)

[dreamsyntax]

Not sure if related, can someone try with the environment variable override per libsdl-org/SDL#10073

[khg8m3r]

@SuperSamus I think the Switch Pro controller was a separate update from 2.30.6 where they improved the reporting mode.

@dreamsyntax I've been looking through the 2.30.0 changes for steam deck and that thread you posted might be the answer I was looking for as they were looking at some of the same PRs I've been trying to understand.
I tried adding the environment variables to the launch command in Steam under the Properties > Launch options > "run" "--env=SDL_HIDAPI_LIBUSB_WHITELIST=0" <rest_of_launch_options>, but it didn't seem to fix it. I'll take another stab at it after work today when I have more time to tinker.