Transition from SDL2 to SDL2 Compat + SDL3

[sunshineinabox]

Replaces SDL2 build with SDL3 as the core library and SDL2-compat shim, allowing existing SDL2-linked apps to continue working.

Changes in this PR:

• SDL3 (3.2.30) replaced SDL2
• SDL2-Compat (2.32.64)
• SDL2_glesonly: Removed — GLES-only libs are now copied in post_makeinstall_target within the SDL2 package instead
• App packages (control-gen, list-guid, oga_controls, sdl2text, mako-osd): Updated include paths from build-dir lookups to SYSROOT_PREFIX, and fixed CXX/CFLAGS variable names. (Unsure about the CFLAGS changed, but looked like a typo to me).
• Patches: DRM resolution and libmali header patches migrated from SDL2 → SDL3.
• KMSDRM always enabled now

TODOs before merge:

• Will require testing on multiple devices
• Currently only building, will start as a draft until I am able to test further (I can test on RK3326 and sm8250)

TODOs Future changes:

• GL_ES2 is flag is not present in Unix config for SDL2-Compat will need to be fixed upstream, there is a hack to allow building for now
• SDL2 should more clearly indicate its SDL2-Compat in the future
• Migrate Rocknix apps to SDL3

[r3claimer]

Awesome. Definitely something in our todo list. Yes will need lots of testing

[loki666]

@sunshineinabox some standalones don't compile

[sunshineinabox]

I’ll take a look through these logs tonight and work through them. It’s strange I imagine it’s probably related to some device dependent conditionals since I was only building for one device.

[loki666]

@sunshineinabox still failing
SM8550 finished building... I'll test that already

[sunshineinabox]

Yea switching from fbdev to EGL introduced more X11 related erros so will have to update those flags then I'll stop making changes so that it can actually be tested. Currently building on my macbook so its been slow goings for builds, unfrotunately!

EDIT: it should also build at e51e49901d2bb0360ddf5041488b4c2681efd95c for all targets.

[sunshineinabox]

https://github.com/sunshineinabox/distribution/actions/runs/22337426588

Builds now

[sunshineinabox]

Some things I've noticed. Seems to work fine with brief testing of emulators (Dreamcast, PSP, N64, GBA, Genesis). Built in apps are broken (I think this is due to SDL2_image, SDL2gfx libraries, but have not made a debug build to confirm, the downside of using a shim. Luckily it has already been ported to SDL3). Still need to test on a more capable device. I cannot test HDMI output so need to ensure the rebased patch works appropriately. Had a heck of a time with formatting of this patch using github codespace so now I'm using vscode locally. Using EGL in PPSSPP will require some guards that prevent defaulting to X11. They are working on transition to SDL3 so I'll wait before putting in effor there and I doubt it will yield significant changes. I think next steps will be migrating built in apps like file manager over to sdl3.

[loki666]

some quick tests on SM8650
so far so good, tools, emulators and portmasters + some ports seems fine

I don't think we need to migrate our tools to SDL3... SDL2 compat will stay there for a while

[sunshineinabox]

I'll have to confirm file manager works on libmali without pr to confirm now that you mention it, ideally it would be easier to just keep sdl2 compat. Will report back after some testing.

[porschemad911]

@sunshineinabox can you please rebase this on distribution HEAD for CI and we will start testing across various platforms.

No conflicts when I did a quick local rebase test:

$ git pull --rebase origin next
From https://github.com/porschemad911/rocknix-distribution
 * branch                  next       -> FETCH_HEAD
Successfully rebased and updated refs/heads/sdl2-compat

[sunshineinabox]

Should be rebased now

[porschemad911]

I will test for S922X.

Issues found with libmali:

• mupenplus64-sa - 4:3 image offset to the right and cropped (rice video plugin - other plugins ok)
• azahar-sa - crashes on launch (vulkan - OpenGL ES ok)
• commander - crashes on launch (segfault)

azahar-sa logs (libmali / vulkan):

runemu.sh: /usr/bin/runemu.sh Executing /usr/bin/bash /usr/bin/start_azahar.sh /storage/roms/3ds/Mario Kart 7 (USA).cxi 3ds
terminate called after throwing an instance of 'vk::LayerNotPresentError'
  what():  vk::createInstanceUnique: ErrorLayerNotPresent

With panfrost:

• mupenplus64-sa - same issue
• commander works fine

[loki666]

I will test for S922X.

Issues found with libmali:

• mupenplus64-sa - 4:3 image offset to the right and cropped (rice video plugin - other plugins ok)
• azahar-sa - crashes on launch (vulkan - OpenGL ES ok)
• commander - crashes on launch (segfault)

azahar-sa logs (libmali / vulkan):

runemu.sh: /usr/bin/runemu.sh Executing /usr/bin/bash /usr/bin/start_azahar.sh /storage/roms/3ds/Mario Kart 7 (USA).cxi 3ds
terminate called after throwing an instance of 'vk::LayerNotPresentError'
  what():  vk::createInstanceUnique: ErrorLayerNotPresent

With panfrost:

• mupenplus64-sa - same issue
• commander works fine

is the RICE issue new to this? I kinda remember RICE plugin is very picky on aspect ratio setup, and something is still wrong in the start script (not working on 1:1 aspect ration screens like RG CubeXX)

[porschemad911]

is the RICE issue new to this? I kinda remember RICE plugin is very picky on aspect ratio setup, and something is still wrong in the start script (not working on 1:1 aspect ration screens like RG CubeXX)

I have not tested on latest nightly to compare, but have frequently tested mupenplus64-sa / rice with libmali in the past with no issue.

[sunshineinabox]

I'm also eperiencing the same issues using libmali (except the Azahar one as RK3326 doesn't really support it)