Screen does not resize properly on fullscreen restore with sdl2-compat

[SRSaunders]

sdl2-compat + SDL3 has recently been introduced on Arch (including Manjaro) and Fedora Linux as a replacement for SDL2. Native SDL2 is no longer installed on these distributions by default. However, sdl2-compat + SDL3 provides a compatibility API for SDL2 applications to allow them to continue running. It is expected that sdl2-compat + SDL3 will migrate to other distros over time. See https://github.com/libsdl-org/sdl2-compat.

When trying RBDoom3BFG on Manjaro (Arch) Linux with sdl2-compat + SDL3, there are a few differences. The most noticeable one is the content area does not resize properly when doing a restore (including Alt-Enter) from Borderless Fullscreen to windowed mode. The other is automatic adjustment for window borders when positioning a window, although this is highly dependent on choice of window manager.

The RBDoom3BFG SDL code requires a few minor changes to fix this, and fortunately these changes are compatible with native SDL2, so should be backwards compatible for non sdl2-compat distros (e.g. Debian, etc).

I will submit a PR to fix this.

[runlevel5]

Many games are now considering to adopt SDL3 rather than supporting both SDL2 and SDL3. For example yquake2 to name a few. As more and more Linux distributions start the migration to SDL3, I think supporting SDL2 can pose a bit of maintenance overhead (unless there is any particular reason to stay on SDL2). So instead of pouring more efforts in providing the backward compatibility, shall we consider move to SDL3 instead?

[SRSaunders]

@runlevel5 there is not a lot of risk in the short term, as sdl2-compat was recently introduced (2025) by the core SDL team and is under active development for migration across linux platforms as well as bug fixes. The intent is clearly to smooth the transition to SDL3 without breaking existing SDL2 apps. For RBDoom3BFG this seems to be largely successful, with only tweaks required in my linked PR above. The effort was small on my part and fully compatible with native SDL2, at least for the platforms I tested on (Manjaro Linux, macOS). Trying this PR on other distros (e.g. Fedora - using sdl2-compat, Ubuntu - using native sdl2, etc.) would help confirm this. If you could try it out on your Fedora/ppc64le machine that would be helpful.

FYI - I can tell that your Fedora machine is currently using sdl2-compat since your log reveals SDL3 events leaking into the SDL2 stream (seen in your other issues posted here), e.g.:

WARNING: unknown event 525 = 0x20d
WARNING: unknown event 516 = 0x204
WARNING: unknown event 527 = 0x20f
WARNING: unknown event 534 = 0x216

In the medium to longer term migratation to native SDL3 is a possibility, but I (and I suspect @RobertBeckebans) would like to look at other options such as GLFW, etc. I have found SDL2 to be very finicky and subject to platform-specific behavioural differences across linux window managers and distros, as well as macOS. Getting the behaviour to be consistent and bug-free was not a lot of fun and required tons of scenario and platform testing.

Rather than just jumping onto SDL3, I think a survey and some prototyping with other options might be worth it. One other thing to consider is unifying the window/input handling under a single technology. Currently there are separate code modules for Windows (using native) vs. Linux/macOS (using SDL). A single unifying technology may simplify things.

[klaussilveira]

NVIDIA's Donut uses GLFW for all samples. However, I imagine migrating all of the SDL2 code would be pretty cumbersome. SDL3 has a few tools to make the migration easier:

https://github.com/libsdl-org/SDL/blob/main/build-scripts/SDL_migration.cocci

https://github.com/libsdl-org/SDL/blob/main/build-scripts/rename_symbols.py