Skip to content
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

Closed
smcv opened this issue Jan 9, 2024 · 3 comments
Closed

[SDL2] Backport detection of GLEW, Cg, plib from sdl2-compat? #8812

smcv opened this issue Jan 9, 2024 · 3 comments

Comments

@smcv
Copy link
Contributor

smcv commented Jan 9, 2024

Some Linux distributions (notably Fedora) patch SDL2 to make it prioritize the wayland driver higher than x11, and some users set SDL_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:

  1. SDL2 could attempt to detect whether the game is linked to an X11-only framework like GLEW, NVIDIA Cg or plib, and if it is, force the x11 video driver. sdl2-compat already does this, but "real" SDL2 does not - should it?
  2. SDL2 could have a quirks table listing known-bad games (matched by their executable name) that need the x11 driver to be forced, or that need the equivalent of SDL2COMPAT_ALLOW_SYSWM=0. sdl2-compat has this quirks table (although it is empty), but "real" SDL2 does not.
  3. SDL maintainers could ask Fedora to stop patching SDL2 in this way, but Fedora maintainers have resisted that in the past.
  4. Steam could explicitly set SDL_VIDEODRIVER=x11 for all games that run in the legacy LD_LIBRARY_PATH environment, or for a subset of games that have been reported as needing this workaround.
  5. Steam users can set the launch options 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.

@slouken
Copy link
Collaborator

slouken commented Jan 9, 2024

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.

@smcv
Copy link
Contributor Author

smcv commented Jan 10, 2024

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:

$ SDL_VIDEODRIVER=wayland SDL2COMPAT_DEBUG_LOGGING=1 SDL_DYNAMIC_API='/usr/$LIB/sdl2-compat/libSDL2-2.0.so.0' widelands                         
INFO: sdl2-compat 2.28.50, built on Jan 10 2024 at 15:12:55, talking to SDL3 3.0.0
INFO: This app appears to be named 'widelands'
INFO: This app looks like it requires X11, but the SDL_VIDEODRIVER environment variable is set to "wayland". If you have issues, try setting SDL_VIDEODRIVER=x11
This is Widelands version 1.1 Release
[00:00:00.000 real] INFO: Set home directory: /home/smcv/.local/share/widelands
[00:00:00.000 real] INFO: Set configuration file: /home/smcv/.config/widelands/config
[00:00:00.000 real] WARNING: No locale translations found in /usr/share/games/widelands/data/locale
[00:00:00.000 real] INFO: selected language: (system language)
[00:00:00.000 real] INFO: using locale en_GB.utf8
[00:00:00.000 real] INFO: Adding directory: /usr/share/games/widelands/data
[00:00:00.001 real] INFO: selected language: (system language)
[00:00:00.001 real] INFO: using locale en_GB.utf8
[00:00:00.002 real] INFO: Byte order: little-endian
Added video capture ID: 1 /dev/video0 (usb-0000:00:14.0-8) (total: 1)[00:00:00.298 real] INFO: Graphics: Try to set Videomode 800x600
[00:00:00.363 real] ERROR: glewInit returns 4
[00:00:00.363 real] ERROR: Your OpenGL installation must be __very__ broken. Unknown error

Caught exception (of type '10WException') in outermost handler!
The exception said: [./src/graphic/gl/initialize.cc:139] glewInit returns 4: Broken OpenGL installation.

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.

@smcv
Copy link
Contributor Author

smcv commented Jan 10, 2024

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).

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants