Celeste SDL2 compatibility issue on wayland

[HugoKirch]

Your system information

• Steam Runtime Version:
• Distribution : Archlinux (linux 6.9.11) with wayland & hyprland
• Link to your full system information (Help -> Steam Runtime Diagnostics) in a Gist: Here
• Have you checked for system updates?: Yes
• What compatibility tool are you using?: None (i think)
• SteamLinuxRuntime versions

Please describe your issue in as much detail as possible:

After installing celeste without any compatibility tool explicitly set, I try to launch it inside of steam.
It does not launch and gives me this error log

Steps for reproducing this issue:

1. Install celeste on linux
2. Launch celeste

I tried to launch celeste with the following launch option:
SDL_VIDEODRIVER=wayland
But it is the same outcome

[smcv]

System.TypeInitializationException: The type initializer for 'Microsoft.Xna.Framework.FNAPlatform' threw an exception. ---> System.Exception: SDL_Init failed: wayland,x11 not available

I see from this and the Steam Runtime Diagnostics report that you have SDL_VIDEODRIVER=wayland,x11 set in the environment. This might be because you have set it like that globally, or it might be like this because recent versions of Steam automatically replace SDL_VIDEODRIVER=wayland with SDL_VIDEODRIVER=wayland,x11 for slightly better compatibility with games that include their own copy of SDL.

I would not recommend forcing this environment variable at all: SDL 2 has limitations in its support for native Wayland that result in good reasons to default to the X11 protocol via Xwayland, even on systems where native Wayland is available. I think you would probably find that Celeste works better if you leave this environment variable unset.

You could unset SDL_VIDEODRIVER for just this one game by setting its Launch Options to:

env -u SDL_VIDEODRIVER %command%

but it would be safer and more generally applicable to leave it unset for the whole system.

Similarly, GDK_BACKEND=wayland,x11,* should not normally be necessary: GTK 3 and 4 normally prefer native Wayland (if available) anyway, only falling back to X11 if native Wayland is not available. It's often better to let libraries behave according to their defaults (which have generally been well-thought-out), and only force non-default behaviour if it is specifically necessary to work around a bug.

From the depot file listing, it looks as though the problem here might be that Celeste has its own private copy of SDL 2 (in lib/libSDL2-2.0.so.0 and lib64/libSDL2-2.0.so.0). If this copy of SDL 2 is too old to support the wayland,x11 syntax for graceful fallback through multiple drivers (which was new in SDL 2.0.16), and is also too old to support native Wayland, then that would explain the symptoms you see.

Recent versions of the Steam Linux Runtime have an experimental mechanism to force individual games to use the Steam Runtime's copy of SDL via SDL's "dynamic API" feature, by setting the game's Launch Options to:

STEAM_COMPAT_RUNTIME_SDL2=1 %command%

You might find that setting that option gives you better results.

I tried to launch celeste with the following launch option: SDL_VIDEODRIVER=wayland

This is usually (always?) going to provide worse compatibility than SDL_VIDEODRIVER=wayland,x11, and I would not recommend it.

---

It's probably unrelated to this particular issue, but Vulkan for 32-bit processes seems to be non-functional on this particular system. For 32-bit games, you might need to install lib32-vulkan-radeon or whatever package provides the 32-bit Nvidia driver, depending which GPU you intend to be using.

[HugoKirch]

I tried both of your fixes and i think that STEAM_COMPAT_RUNTIME_SDL2=1 %command% is as you said the setting with the best results.

And by the way thanks for this crystal clear answer ! You made my day haha

[smcv]

I tried both of your fixes and i think that STEAM_COMPAT_RUNTIME_SDL2=1 %command% is as you said the setting with the best results.

Please report this issue to the game's developer/publisher: ideally native Linux game releases on Steam should rely on the Steam Runtime's frequently-updated version of SDL instead of providing their own, which would mean that you would not need to use that workaround.