Fedora project's proposal:

https://fedoraproject.org/wiki/Changes/SDL12onSDL2

Thread with discussion of package lists:

https://twitter.com/icculus/status/1398319367222444034

Some initial automation work:

https://github.com/libsdl-org/sdl12-compat/issues/34#issuecomment-847326194

dosbox-0.74 on CentOS-6.10 / i686.

With 'normal' SDL-1.2, dosbox doesn't respect my keyboard layout (which is Turkish-F) and behave as is I were using US layout.

With sdl12-compat (latest git master) talking to SDL2-latest git master, it does use my keyboard layout but not fully correctly:

• The key next to left-shift should report <, > or | (plain, with shift, with AltGr) but it prints \, | or none: all behaving like US-layout.

• The key next to right shift should report , or ; (plain or shift), but it prints , (which is good) or < (bad: US-layout).

• The key left to it should report . or :, but it prints . (good) or > (bad: US-layout).

• Similar stuff with the keys on the numbers' row -- e.g. the key below Esc prints nothing, ...

We have stubs for cdrom code in sdl12-compat.

Should we import the code from SDL-1.2? If we ever do that, would there be licence issues (can any of the authors still be reached, etc)?

If we'll keep the stubs, close this.

[Just dropping my notes about this here: I may split things up and/or fix them if I get some time…]

There are a large number of issues with Civilization: Call to Power v1.2a (it being an ancient SDL 1.1 game with a bunch of glibc/libstdc++ incompatibilities). Getting it to run even with real SDL 1.2 on a modern system (i.e., with modern glibc, etc, dynamically linked) is a chore, involving a lot of hex editing and patching. See: https://gist.github.com/sulix/09f059c468fcb58eefbca8ef46006ccb

That being said, while it does crash occasionally regardless, it does work considerably better with the real SDL 1.2 than with sdl12-compat. Maybe some of the issues could affect other games as well:

• [X] SDL_INIT_EVENTTHREAD: CivCTP uses this, and doesn't often call SDL_PumpEvents() otherwise. Hacked around by calling SDL_PumpEvents() from within SDL_PeepEvents(). There may need to be more work on it to fix the next issue, though…
• [x] Multithreaded SDL_UpdateRects(): CivCTP calls SDL_UpdateRects() from two different threads, only one of which is the original thread. Under wayland (and nvidia+x11), this results in eglMakeCurrent failing in the renderer, and the texture locking/reupload failing a lot of the time (mouse cursor only visible sometimes, YUV overlays show up green, etc). It might be contributing to the random crashing in the renderer/Mesa on X11/Intel, too. Maybe we should keep a shadow surface in local memory (without needing to call into GL to lock it each call), and then defer the actual updates to present, which we can defer to the main thread? Though that might not work, as the "main" thread might not be doing any SDL calls at all during some parts of the game…
• [x] Stack realignment: CivCTP's stacks are 4-byte aligned. Most distros are built with 16-byte aligned stacks to use SSE. Use __attribute__((force_align_arg_pointer)) to realign stacks in sdl12-compat to bridge this gap.
• [x] CD audio / game audio device re-opening: The format conversion between the 22050/mono/8bit and 44100/stereo/16bit big-endian when mixing CD audio and SDL audio is broken if the (real) device is closed/re-opened to pick a better common format. Forcing sdl12-compat to always open the real device at 44100/stereo/16bit works around this, but there's clearly a real bug here.
• [x] SDL_FreeYUVOverlay() should reset QueuedDisplayOverlay12 = NULL;: I don't think this is the cause of any of the issues, but seems like it's a real bug.
• [X] X11 Usage: CivCTP calls XNextEvent, XSync, XGetWindowAttributes, XFree, XInternAtom, XSendEvent and XQueryPointer. This doesn't seem to cause any issues, though, even under Wayland?

• Debian 10 host system, AMD GPU, Mesa
• run Steam with a modified Steam Runtime that contains sdl12-compat 1.2.52 instead of "real" SDL 1.2
• launch https://store.steampowered.com/app/204300/Awesomenauts__the_2D_moba/

Expected result: normal gameplay

Actual result: a black window with no titlebar or borders (but the game is running and sounds still play)

There are a bunch of FIXME()s that it'd be nice to get to: even if we don't get to fix them, it'd be nice to have some of them only trigger when they're more likely to indicate an actual problem with the running application. Now that FIXMEs are disabled by default, it's not as confusing as it could be, though.

Originally posted by @sulix in https://github.com/libsdl-org/sdl12-compat/issues/53#issuecomment-972897416

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified Reported for operating system, platform: Other, x86

Comments on the original bug report:

On 2019-03-13 19:45:13 +0000, Ryan C. Gordon wrote:

Most of the sdl12-compat code will work out of the box on Windows, but I probably need to sort out the SDL_main politics.

--ryan.

On 2019-03-14 17:13:16 +0000, Rohit Nirmal wrote:

A few notes:

1. CloseSDL20Library() for _WINDOWS has an extra open bracket that causes compile errors.
2. On MinGW, _WINDOWS is not defined, causing the #error to trigger.
3. stdio.h needs to be #included for stderr.
4. stdlib.h needs to be #included to avoid an implicit declaration warning for abort().
5. On MinGW, SDL20_CreateMutex and SDL20_CreateSemaphore are undefined for some reason. As a quick fix, I changed them to SDL20_SYM from SDL20_SYM_PASSTHROUGH in SDL20_syms.h and created SDL_CreateMutex and SDL_CreateSemaphore functions in SDL12_compat.c to simply call them.

Last I tested this on my Rockchip RK3328 using an application compiled for GBM and GLES2. I dropped this in place of the SDL1.2 library, the application crashed as it was initializing it's graphics stack. It was months ago so wanted to check if this was a known issue and has since been resolved or if I should plan to get logs for a future issue report. Thanks in advance!

Here's the proposed patch

diff -ru orig/sdl12-compat-release-1.2.52/include/SDL/SDL_syswm.h ./src/sdl12-compat-release-1.2.52/include/SDL/SDL_syswm.h
--- orig/sdl12-compat-release-1.2.52/include/SDL/SDL_syswm.h    2022-03-03 06:56:56.000000000 -0800
+++ ./src/sdl12-compat-release-1.2.52/include/SDL/SDL_syswm.h   2022-05-06 14:33:23.409605790 -0700
@@ -109,7 +109,7 @@
         typedef struct SDL_SysWMinfo
         {
             SDL_version version;
-            int data;
+            void *data;
         } SDL_SysWMinfo;

 #       include "close_code.h"
diff -ru orig/sdl12-compat-release-1.2.52/src/SDL12_compat.c ./src/sdl12-compat-release-1.2.52/src/SDL12_compat.c
--- orig/sdl12-compat-release-1.2.52/src/SDL12_compat.c 2022-03-03 06:56:56.000000000 -0800
+++ ./src/sdl12-compat-release-1.2.52/src/SDL12_compat.c        2022-05-06 13:15:12.647937592 -0700
@@ -6220,6 +6220,16 @@
     SDL_SysWMinfo info20;

     if (info12->version.major > 1) {
+        if (info12->version.major == 2) {
+#if defined(SDL_VIDEO_DRIVER_WINDOWS)
+            info12->window = (HWND)VideoWindow20;
+#elif defined(SDL_VIDEO_DRIVER_X11)
+            info12->info.x11.gfxdisplay = (Display *)VideoWindow20;
+#else
+            info12->data = (void *)VideoWindow20;
+#endif
+            return 1;
+        }
         SDL20_SetError("Requested version is unsupported");
         return 0;  /* some programs only test against 0, not -1 */
     } else if (!SupportSysWM) {

This facilitates SDL1.2 application to be used with SDL2 loadable plugins (DLL/lib.so/dylib) that can render into main window. In an ideal world that said SDL1.2 application should have been ported to SDL2 to be able to use SDL2 plugins. Unfortunately, this isn't always the case. Plumbing existing SDL1.2 SDL_GetWMInfo() to allow retrieval of SDL_Window enables that said SDL1.2 application to use SDL2 plugins with the least effort.

Noticed this in RedHat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2037565

tucnak & associated libzia: http://tucnak.nagano.cz

As noted in the original bug report, video is broken with sdl12-compat but not with real SDL-1.2. Reproduced the coredump, which happens with SDL2 built with -O3 but not with lower optimization levels for me:

(gdb) bt
#0  0x00164424 in __kernel_vsyscall ()
#1  0x008f87c1 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0x008fa09a in abort () at abort.c:92
#3  0x009386c5 in __libc_message (do_abort=2, fmt=0xa27910 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:198
#4  0x0093ec31 in malloc_printerr (action=<value optimized out>, str=<value optimized out>, ptr=0xb6203e80, ar_ptr=0xb6200010) at malloc.c:6360
#5  0x00941691 in _int_free (av=0xb6200010, p=0xb6203e78, have_lock=0) at malloc.c:4846
#6  0x012918dc in ?? () from /usr/lib/dri/radeonsi_dri.so
#7  0x0129c8cf in ?? () from /usr/lib/dri/radeonsi_dri.so
#8  0x00fa4350 in ?? () from /usr/lib/dri/radeonsi_dri.so
#9  0x00fa01a9 in ?? () from /usr/lib/dri/radeonsi_dri.so
#10 0x00fa73eb in ?? () from /usr/lib/dri/radeonsi_dri.so
#11 0x00e4eb2b in ?? () from /usr/lib/dri/radeonsi_dri.so
#12 0x07caf156 in shared_dispatch_stub_203 () from /usr/lib/libglapi.so.0
#13 0x0033c733 in GL_RunCommandQueue (renderer=0x854a830, cmd=0x87bf2a8, vertices=0x8895ab8, vertsize=120) at /home/ozzie/3/SDL/src/render/opengl/SDL_render_gl.c:1291
#14 0x00329a07 in FlushRenderCommands (renderer=0x854a830) at /home/ozzie/3/SDL/src/render/SDL_render.c:244
#15 0x00329d37 in SDL_RenderPresent_REAL (renderer=0x854a830) at /home/ozzie/3/SDL/src/render/SDL_render.c:4225
#16 0x002f2ede in SDL_RenderPresent (a=0x854a830) at /home/ozzie/3/SDL/src/dynapi/SDL_dynapi_procs.h:377
#17 0x00289273 in PresentScreen () at SDL12_compat.c:5839
#18 0x00289e55 in SDL_PumpEvents () at SDL12_compat.c:6113
#19 0x08102bfc in sdl_event_thread (handle=0xe) at tsdl.c:998
#20 0x00b42680 in ?? () from /lib/libglib-2.0.so.0
#21 0x00a99bc9 in start_thread (arg=0xb6da7b70) at pthread_create.c:301
#22 0x009b111e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133

The segmentation fault seems to go away by the following change, but the broken video remains. (The change to PresentScreen() is the segfault fix, zeroing PendingKeydownEvent in Quit12Video() is possibly unnecessary...)

diff --git a/src/SDL12_compat.c b/src/SDL12_compat.c
index 0b13d95..db22c30 100644
--- a/src/SDL12_compat.c
+++ b/src/SDL12_compat.c
@@ -2137,6 +2137,7 @@ Quit12Video(void)
     VideoInfoVfmt20 = NULL;
     EventFilter12 = NULL;
     EventQueueAvailable = EventQueueHead = EventQueueTail = NULL;
+    SDL20_memset(&PendingKeydownEvent, 0, sizeof(SDL12_Event));
     SDL_FreeCursor(CurrentCursor12);
     VideoModes = NULL;
     VideoModesCount = 0;
@@ -5825,6 +5826,10 @@ SDL_DisplayFormatAlpha(SDL12_Surface *surface12)
 static void
 PresentScreen(void)
 {
+    if (!VideoRenderer20) {
+        return;
+    }
+
     SDL20_RenderClear(VideoRenderer20);
     SDL20_RenderCopy(VideoRenderer20, VideoTexture20, NULL, NULL);
 

CC: @Conan-Kudo

During a review, it was discovered that there is some code that's listed under the terms of the SGI Free B v1.1 license:

https://github.com/libsdl-org/sdl12-compat/blob/c0504eb42c7cabc23c6b4a16f5915ee49962ddff/include/SDL/SDL_opengl.h#L1-L30

This license is non-free, but it's easy enough to fix as the license has a clause to allow upgrading to the SGI Free B v2.0 license (which is effectively MIT).

Can the license terms be updated accordingly?

User reported that grafx2 would no longer start at all on Fedora 37, but only on xorg (works fine on wayland). Confirmed locally.

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Resource id in failed request:  0x0
  Serial number of failed request:  315
  Current serial number in output stream:  316

Passing SDL12COMPAT_ALLOW_SYSWM=0 quirk resolves the crash, but I was not sure if it would be appropriate to add grafx2 to the list of binaries needing this value or if there was a more appropriate code fix for grafx2 (it is FOSS).

Alpha Centauri used to be provided with a native engine developed by Loki, that can still be used with ./play.it (using the game build sold on GOG as a basis): https://www.dotslashplay.it/en/games/alpha-centauri

One of the differences I noticed when using the sdl12-compat wrapper instead of real SDL 1.2 is that the initial animation of the pod landing is very sluggish, while it is smooth with the old SDL 1.2 library.

Since this would require access to a commercial game for investigating the issue, I would be OK to buy a gift code to someone willing to work on this issue but does not own a copy of the game yet.

I am of course willing to provide more information, but since I’m quite new to anything related to SDL I would need step-by-step instructions on how to debug the issue.

With https://github.com/libsdl-org/sdl12-compat/commit/67f8b3a85b782eefb4db90f34d5b0742ef2cb5fc (1.2.58 + 29 commits) the copyright message, explosion and CRASHED appear as expected, but on Wayland the game sometimes (50%) becomes unresponsive anyway. With X11 it seems to be reliable?

Originally posted by @smcv in https://github.com/libsdl-org/sdl12-compat/issues/253#issuecomment-1289059180

Prerequisites:

• Debian testing (Debian 12 alpha)
• Video: GNOME 43 in Wayland mode (with Mesa 22.2.0 on AMD Vega, if it matters)
• Audio: Pipewire 0.3.59, with pipewire-pulse emulating PulseAudio
• apt install tuxfootball (Debian package version 0.3.1-7)
• Some relevant libraries:
  • libsdl1.2-compat either 1.2.58-1 (packaged in Debian experimental) or commit 63e4393 (locally built)
  • libsdl2-2.0-0 version 2.24.1+dfsg-1
  • libsdl-image1.2 version 1.2.12-13+b1
  • libsdl-mixer1.2 version 1.2.12-17+b2
  • libsdl1.2debian (real SDL 1.2) version 1.2.15+dfsg2-8

To reproduce:

• tuxfootball
• LD_LIBRARY_PATH=.../sdl12-compat/_build tuxfootball
• SDL_VIDEODRIVER=wayland LD_LIBRARY_PATH=.../sdl12-compat/_build tuxfootball

and press Up/Down arrow keys.

Expected result: selected option is white, remaining options are gold

Actual result: Real SDL 1.2 works. With sdl12-compat, the selected option vanishes.

Gameplay seems OK as far as I can tell.

Prerequisites:

• Debian testing (Debian 12 alpha)
• Video: GNOME 43 in Wayland mode (with Mesa 22.2.0 on AMD Vega, if it matters)
• Audio: Pipewire 0.3.59, with pipewire-pulse emulating PulseAudio
• apt install barrage (Debian package version 1.0.5-1)
• Some relevant libraries:
  • libsdl1.2-compat commit 63e4393 (locally built) to avoid #230
  • libsdl2-2.0-0 version 2.24.1+dfsg-1
  • libsdl-image1.2 version 1.2.12-13+b1
  • libsdl-mixer1.2 version 1.2.12-17+b2
  • libsdl-sound1.2 version 1.0.3-9+b1
  • libsdl1.2debian (real SDL 1.2) version 1.2.15+dfsg2-8

To reproduce:

• asc
• LD_LIBRARY_PATH=.../sdl12-compat/_build asc
• SDL_VIDEODRIVER=wayland LD_LIBRARY_PATH=.../sdl12-compat/_build asc

Expected result: mouse can be moved anywhere

Actual result: real SDL 1.2 works. With sdl12-compat the mouse is confined to a subset of the screen and cannot enter the menu bar. The exact bounds seem to be unpredictable (uninitialized?)

Prerequisites:

• Debian testing (Debian 12 alpha)
• Video: GNOME 43 in Wayland mode (with Mesa 22.2.0 on AMD Vega, if it matters)
• Audio: Pipewire 0.3.59, with pipewire-pulse emulating PulseAudio
• apt install freedroid (Debian package version 1.0.2+cvs040112-7) (not to be confused with 3D freedroidrpg, which is different)
• Some relevant libraries:
  • libsdl1.2-compat either 1.2.58-1 (packaged in Debian experimental) or commit 63e4393 (locally built)
  • libsdl2-2.0-0 version 2.24.1+dfsg-1

To reproduce:

• freedroid
• LD_LIBRARY_PATH=.../sdl12-compat/_build freedroid
• SDL_VIDEODRIVER=wayland LD_LIBRARY_PATH=.../sdl12-compat/_build freedroid

Each time, click once to pass the Briefing screen, then a second time to pass the description of your robot.

Expected result: all work

Actual result: with sdl12-compat, it crashes.

Video info summary from SDL:
----------------------------------------------------------------------
Is it possible to create hardware surfaces: no
Is there a window manager available: yes
Are hardware to hardware blits accelerated: no
Are hardware to hardware colorkey blits accelerated: no
Are hardware to hardware alpha blits accelerated: no
Are software to hardware blits accelerated: no
Are software to hardware colorkey blits accelerated: no
Are software to hardware alpha blits accelerated: no
Are color fills accelerated: no
Total amount of video memory in Kilobytes: 262144
Pixel format of the video device: bpp = 32, bytes/pixel = 4
Video Driver Name: wayland
----------------------------------------------------------------------
Found new graphics-theme: classic 
Found new graphics-theme: lanzz 
Found new graphics-theme: para90 
Game starts using theme: classic
Segmentation fault (core dumped)

#0  SDL_ListRemove (head=0x55b900e608a8, ent=ent@entry=0x55b9a5f4dce0) at ./src/SDL_list.c:70
#1  0x00007f49e83801eb in SDL_InvalidateMap (map=0x55b9a5f4dce0) at ./src/video/SDL_pixels.c:1052
#2  SDL_MapSurface (src=src@entry=0x55b9a5f4d7c0, dst=dst@entry=0x55b9a5e60870) at ./src/video/SDL_pixels.c:1075
#3  0x00007f49e83847ca in SDL_LowerBlit_REAL (src=0x55b9a5f4d7c0, srcrect=0x7ffcaf3e5d80, dst=0x55b9a5e60870, dstrect=0x7ffcaf3e5e00)
    at ./src/video/SDL_surface.c:701
#4  0x00007f49e8384a59 in SDL_UpperBlit_REAL (src=0x55b9a5f4d7c0, srcrect=<optimized out>, dst=0x55b9a5e60870, dstrect=0x7ffcaf3e5e00)
    at ./src/video/SDL_surface.c:807
#5  0x00007f49e8aef62c in SDL_UpperBlit
    (src12=0x55b9a5f4dd70, srcrect12=<optimized out>, dst12=0x55b9a5e60970, dstrect12=0x7ffcaf3e5e48)
    at /home/desktop/tmp/sdl12-compat/src/SDL12_compat.c:4772
#6  0x000055b9a3b26e07 in PutInfluence (x=x@entry=-1, y=y@entry=-1) at view.c:290
#7  0x000055b9a3b27ee4 in Assemble_Combat_Picture (mask=mask@entry=2) at view.c:228
#8  0x000055b9a3b0c9ea in main (argc=<optimized out>, argv=<optimized out>) at main.c:140