libsdl-org
wayland app/driver blacklisting
Would be acceptable switch to wayland as a default in next release, with precautions as:
- blacklist problematic drivers - (older) Nvidia driver
- applications which has serious unresolved issues - proprietary ones or very complex to easily fix
? I agree that safest way is to let application developer to enable Wayland in the code, but f.e. for application which are run on Linux mobile devices (where is usually wayland video driver forced) it may impose unnecessary issues, which would be solved if the developer on modern wayland desktop seen the application misbehave and was able to adjust it.
The possibility of an application-specific "quirks" system was brought up in #5527, whether as part of SDL or as part of something like Steam.
sdl12-compat has such a system: https://github.com/libsdl-org/sdl12-compat/blob/main/src/SDL12_compat.c#L1151
Throwing this out there in case anyone plays around with it: You will probably want to attempt this in src/video/wayland/SDL_waylandvideo.c at Wayland_CreateDevice. It would probably be a list similar to sdl12-compat, but it just returns 0 immediately if it's a recognized borked title.
The system makes sense with sdl12-compat since it's mostly targeting older, unmaintained games using a very old API. I'm less sure this makes sense in SDL2 given that distributions update drivers, games get fixed, Wayland gets improved, etc. This is probably better done at the distribution level or in game launchers using the SDL_VIDEODRIVER environment variable. I think the current choice to default to X11 is the right one for the broad general case at this time, and users or distributions that have more specific knowledge of their games and runtime environment can enable Wayland as desired.
The system makes sense with sdl12-compat since it's mostly targeting older, unmaintained games using a very old API. I'm less sure this makes sense in SDL2 given that distributions update drivers, games get fixed, Wayland gets improved, etc. This is probably better done at the distribution level or in game launchers using the SDL_VIDEODRIVER environment variable. I think the current choice to default to X11 is the right one for the broad general case at this time, and users or distributions that have more specific knowledge of their games and runtime environment can enable Wayland as desired.
I had the same thought, but I underestimated the degree that quirks could step all over everything even if they take up a small percentage of the catalog. In my own tests, for example, I covered a very broad percentage (including Unity, UE4/5, Source, XNA, Clickteam, custom engines, etc), but did not anticipate titles like Braid (and even whole middlewares like Cg) throwing a wrench into the plan like they ultimately did. This is a harsh contrast to what you and I were thinking, where developers are definitely eager to move to Wayland and will make the effort to refresh the back catalog to do so. I don't want to deny progress in this area (needless to say, anyone who's worked with X is eager to have it in their rear-view mirror) but we do have that obligation to avoid breaking userspace as much as possible at the same time. And, to be blunt, those launchers had the opportunity to participate and completely failed to do so, regardless of how much advance notice they had (and they definitely had a lot, and I'll happily contest any argument to the contrary).
All that said, the main reason I'm open to this is because I genuinely don't think the quirk list will be that large, and I would be more than happy to put in the work at the application level to make the quirk system unnecessary within a reasonable timeframe. If a Higher Power could allow me to fix those older titles I absolutely would, without question.
As someone who intends to ship SDL2 with Wayland by default, I would definitely like to see some kind of quirks list to deal with forever broken games (like Braid) or games that use things like Cg (which are basically abandonware...).
I admit that personally, I could go either way on this but suspect it's probably only really worth it if there are plans to override the versions of SDL provided with games.
The problem with having a simple quirks list à la the sdl12-compat one, is that it could discourage developers from fixing games: they'd have to rename the game binary, or wait for another SDL release to remove them from the list. I don't think that's a problem for "legacy" APIs like SDL-1.2, where if anyone tries to update their game and complains, the answer is "switch to SDL2".
Now, if we wanted to do something really fancy like trawling through the imported libraries, and defaulting to X11 if X or Cg were loaded, that'd be a bit more flexible, but I don't think anyone really wants to put an ELF parser in SDL…
(Personally, I think that the right place for some sort of per-executable quirks mechanism would be ld-linux.so, but I have my doubts that glibc upstream would be thrilled with the idea…)
On the bright side, almost all the games I've tried which require X11 bundle their own libSDL, so unless you plan to force SDL_DYNAMIC_API or SDL_VIDEODRIVER directly, I don't think too many things would break… (And there are definitely games which ship things like pre-2.0.0 SDL2 builds which have incompatible ABIs, so that sort of override would need a lot of work to get working completely.) Even if the plan is to really encourage people not to ship SDL2 with their games, I think most of the existing broken ones do.
On a somewhat related topic (apologies for the hijacking): if incredibly ugly hacks are your style, it turns out it is possible to patch Cg enough to get it working under SDL2/Wayland, at least enough for Braid and a couple of other games to run.
Basically, I wrote a hacky implementation of the needed GLX functions (either NOPs or passthroughs to SDL) here: https://gist.github.com/sulix/fe951daaeb4e51dfb329e5935e705cbf
(And pre-built for x86 and x86-64.)
For many games (including the SDL-1.2 versions of braid, via sdl12-compat), just loading it with LD_PRELOAD is enough. For others (particularly the Steam/SDL2 version of Braid), you need to do a nastier dance of patching libCgGL.so to load a new library:
mv libglx_wrapper32.so libCgWL.so
perl -pe 's/libGL.so.1/libCgWL.so/' <libCgGL.so.bak >libCgGL.so
However, they work pretty well with Wayland otherwise: there's an absolutely horrible issue with mouse movement in the jigsaw puzzles in Braid, but otherwise it seems to be perfect.
I think he refers to the whole issue. This issue should probably go to sdl2-compat.
Woops, should have read the thread... not sure about the GLX stubs but the quirks can definitely be moved to sdl2-compat.