-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SDL2] Backport detection of GLEW, Cg, plib from sdl2-compat? #8812
Comments
Backporting the X11 requirement checking from sdl2-compat seems reasonable. I've gone ahead and done that in bd2f1e9. This allows users to override the default behavior, but if no video driver has been set and one of those frameworks is linked into the application, we'll default to X11. |
For reference, some open-source games that make convenient test targets for this: Widelands is linked to GLEW and crashes when asked to use Wayland, making it a typical example of the problem scenario:
Endless Sky is linked to GLEW but runs OK in native Wayland anyway (this is surprising, I don't know what's going on here). The ioquake3 family (including OpenArena, iortcw, OpenJK) are an example of games that don't use GLEW or similar, and run fine with native Wayland. |
See endless-sky/endless-sky#7027 and nigels-com/glew#273: it seems it's possible to use GLEW in a way that tolerates successful EGL initialization with no GLX, it's just that most GLEW games don't do this, and instead crash out like Widelands does. |
Some Linux distributions (notably Fedora) patch SDL2 to make it prioritize the
wayland
driver higher thanx11
, and some users setSDL_VIDEODRIVER=wayland
in their session environment.Users in either of these situations are often surprised when a game implicitly assumes that the only video backend that exists on Linux is X11, and mixes SDL windowing with direct use of an X11-only framework like GLEW, NVIDIA Cg or plib, or with direct use of X11 function calls. This tends to result in bug reports that blame SDL, Steam or the Steam Runtime for the game's assumptions, rather than the game itself. For example, in ValveSoftware/steam-runtime#636 a Fedora user reports that Brigador doesn't work when the Steam Runtime loads Fedora's SDL, although either
SDL_VIDEODRIVER=x11
or enabling the Steam Linux Runtime 1.0 (scout) container runtime will work around that issue.Even if we (correctly?) redirect the blame for this to individual games, there is a long tail of pre-2020s games that are no longer maintained by their respective developers or publishers, and will probably never be fixed to be fully native-Wayland-friendly.
Some possible ways to mitigate this:
x11
video driver. sdl2-compat already does this, but "real" SDL2 does not - should it?x11
driver to be forced, or that need the equivalent ofSDL2COMPAT_ALLOW_SYSWM=0
. sdl2-compat has this quirks table (although it is empty), but "real" SDL2 does not.SDL_VIDEODRIVER=x11
for all games that run in the legacyLD_LIBRARY_PATH
environment, or for a subset of games that have been reported as needing this workaround.SDL_VIDEODRIVER=x11 %command%
for affected games.The long-term answer is to replace SDL2 with sdl2-compat, and use sdl2-compat's quirks mechanism, but we cannot do that in the Steam Runtime or in non-experimental distributions until SDL3 is API- and ABI-stable (SDL 3.2.0), so a shorter-term approach might be good to have.
The text was updated successfully, but these errors were encountered: