Migrate from SDL2 to SDL3 3.4.2

[lijunyu-cn]

Also fixed crashes if game controllers disconnect/reconnect more than 8 times. Tested under Windows, testing under Linux and Mac needed.

[Squall-Leonhart]

SDL_main is used incorrectly, it won't build on anything other than windows

[lijunyu-cn]

SDL_main is used incorrectly, it won't build on anything other than windows

Thanks, I will try fix this.

[Exzap]

Implementing the mutex like this isn't safe. Inserting or erasing elements in an unordered_map can invalidate iterators. So what can happen is that by the time you access it->second on this line of code it's already no longer valid because another thread modified m_motion_states.

I believe your reason for using a mutex per-entry is that it's more efficient? But in this case it's not worth the hassle. You can just use one global (static) mutex and then wrap the map and iterator access in that.

[lijunyu-cn]

You're right, I didn't consider it thoroughly enough.

[Exzap]

Current build failure could be due to caching or some dependency still pulling in SDL2. I'll look into it

[Squall-Leonhart]

the logs say theres a failure to upload nupkgs to the cemu nuget repository?

[lijunyu-cn]

It can be roughly determined that the Ubuntu build failure is due to a wayland conflict between wxWidgets and SDL3. Disable wayland feature in SDL3 can make a build success, but not sure what downside it is.

[Squall-Leonhart]

quickfix, set the linker flag -Wl,-z,muldefs this is safe here because both symbols are built from the same wayland definition.

the build failure is because both SDL3 and WxGTK export a wayland symbol wp_pointer_warp_v1_interface
unless its safe to disable wayland in SDL3?

[Exzap]

It can be roughly determined that the Ubuntu build failure is due to a wayland conflict between wxWidgets and SDL3. Disable wayland feature in SDL3 can make a build success, but not sure what downside it is.

This should be fine. We only use the input part of SDL3.

[lijunyu-cn]

Remaining issues

1. SDL thread safety assertion failure in Debug builds. This issue has existed since SDL2, but it was not triggered because SDL2's assertions might have had logic loopholes.

2. Destructors for InputManager and the classes it manages are never triggered, thus exiting without executing resource release operations like SDL_Quit. Additionally, one or more of these destructors cause a deadlock.

3. SDL2 and SDL3 require that initialization, event handling, and quit functions should only be used on the "main thread". We currently only use its input part (additionally, some video functionality is used in the screensaver disabling module, and because initialization is not on the "main thread", this code causes crashes on macOS). For the sake of functional modularity, I think it is acceptable to keep SDL event handling in a thread created by SDLControllerProvider as it is currently done, but SDL initialization and quit functions must also be placed in this thread. This complies with the "main thread" requirements for Windows and Linux. macOS has different "main thread" requirements, but as long as SDL video functions are not used in this "main thread", the input functionality should be usable on macOS just like in SDL2.