This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch to fix the issue (file_4948.txt, text/plain, 2020-01-13 18:20:39 +0000, 9532 bytes)

Reported in version: HG 1.2 Reported for operating system, platform: Linux, All

Comments on the original bug report:

On 2020-01-13 18:20:39 +0000, Paul Cercueil wrote:

Created attachment 4164 Patch to fix the issue

From the patch:

"Implement triple-buffering using a dedicated thread which will wait on VSYNC and then flip the two back buffers."

On 2020-09-22 02:11:12 +0000, Ozkan Sezer wrote:

The patch is in. Thanks. http://hg.libsdl.org/SDL/rev/3dfb9493a246

The patch enables retrievable info->nsWindowPtr type from SDL_GetWMInfo() to enable foreign window conversion in SDL2 plugins. Fixed class collision warning on SDLTranslatorResponder when both SDL1.2 and SDL2 dylib are loaded at the same time.

sha256sum 26d450371967cce1bd169c46cdedee1e98d2acd07dd14d1a25ee2aa7c2655779 0005-GetWMInfo.txt

From README.Wince, we can read this information:

- Landscape mode and automatic rotation of buttons and stylus coordinates.
  To enable landscape mode make width of video screen bigger than height.
  For example: 
    SDL_SetVideoMode(320,240,16,SDL_FULLSCREEN)

However, this does not seem to be true, at least with the source into the repo at the time of writing. Making Width > Height does not rotate the screen. I don't know if:

• this is a bug
• it is something unimplemented.
• it is something removed from the code in the past
• or it not expected to be done in this way

...but at the moment the library does not change from portrait to landscape when you follow the instructions written into the readme file. Instead, if you create a 320x240 screen on a 240x320 device, it simply overflows the space on the display.

I'm still trying to work out the root cause of this but this is what I have so far:

• DirectFB itself works fine, the native DirectFB demos work on the targets (armhf and amd64)
• The apps seem to be OK as they work when using the fbdev backend
• The apps seem to crash because they are getting a null pointer for the framebuffer, they seem to get a workable address at some point because you can see stuff getting drawn to the screen
• The problem seems to come right after the framebuffer mode is getting changed.

FWIW: I know SDL1 is dead, DirectFB was basically dead too (it's recently been forked and getting some love again), the target platform can only run SDL2 with the DirectFB backend because it doesn't have a GPU to run the KMSDRM backend. I also want to run some SDL1 apps that haven't been ported... so getting the DirectFB backend working is the easiest route to having both SDL2 and SDL1 working on this machine.

environment

SDL: 1.2.15 gcc: Apple clang version 13.0.0 (clang-1300.0.29.3)

SDL doesn't render anything on MacOSX 11.5.1.

I confirm that the picture exists.

expect: render hello.bmp

result: nothing

code: src/window.c

#include <SDL/SDL.h>

#undef main
int main(int argc, char *argv[])
{
  SDL_bool quit = SDL_FALSE;
  SDL_Event event;
  SDL_Init(SDL_INIT_EVERYTHING);

  SDL_Rect rect = {0, 0, 100, 100};
  
  SDL_Surface* window = SDL_SetVideoMode(480, 480, 32, SDL_SWSURFACE);
  SDL_Surface* hello = SDL_LoadBMP("../preview2.bmp");
  if (hello == NULL) {
    printf("read bmp error\n");
  }
  SDL_BlitSurface(hello, NULL, window, NULL);
  SDL_WM_SetCaption("hello sdl", "logo.png");
  SDL_Flip(window);

  while (!quit)
  {
    while (SDL_PollEvent(&event))
    {
      if (event.type == SDL_QUIT) {
        quit = SDL_TRUE;
      }
    }
  }
  
  SDL_FreeSurface(hello);
  SDL_Quit();
  return 0;
}

CMakeLists.txt

cmake_minimum_required(VERSION 3.5)
set(project_name sdl-demo)
project(${project_name})

add_executable(${project_name} src/window.c)
target_include_directories(${project_name} PUBLIC ~/Library/SDL ~/Library)

target_link_libraries(${project_name} /Users/lan/Library/SDL/SDL)

Calling SDL_SetVideoMode with (640, 480, 0, SDL_FULLSCREEN) freezes the application on Windows 8.1 with windib video driver.

The reason is ChangeDisplaySettingsA does not return on line 763 in SDL_dibvideo.c . Tried add CDS_TEST to the flags and that seems to work, but as soon as the display would be changed the function does not return. Without SDL_FULLSCREEN the application runs just fine too.

According to Microsoft, the minimum resolution of the applications is 1024x768 from Windows 8+. It seems that they forgot to update ChangeDisplaySettingsA to reflect on this new requirement.

Apparently they dropped this requirement in Windows 10...

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.15 Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2015-01-12 12:02:20 +0000, Petr Pisar wrote:

This is a bug report regarding not calling XInitThreads(). Especially if underlying OpenGL implementation uses threads. It's copied from a Fedora bug report https://bugzilla.redhat.com/show_bug.cgi?id=1181085:

Some libGL implementations call XInitThreads() on dlopen. For example, the latest nVidia proprietary implementation does it, probably because it needs to use threads for performance. This causes applications that use SDL 1.2 to crash.

From XInitThreads(3):

The XInitThreads function initializes Xlib support for concurrent threads. This function must be the first Xlib function a multi-threaded program calls, and it must complete before any other Xlib call is made.

From https://wiki.libsdl.org/SDL_GL_LoadLibrary:

This should be done after initializing the video driver, but before creating any OpenGL windows. If no OpenGL library is loaded, the default library will be loaded upon creation of the first OpenGL window.

But SDL_VideoInit() calls XOpenDisplay() and nVidia libGL implementation calls XInitThreads() on dlopen:

	(gdb) break XInitThreads
	Function "XInitThreads" not defined.
	Make breakpoint pending on future shared library load? (y or [n]) y
	Breakpoint 1 (XInitThreads) pending.
	(gdb) run
	Starting program: /mnt/data/home/woky/src/xonotic/darkplaces/darkplaces-sdl 
	[Thread debugging using libthread_db enabled]
	Using host libthread_db library "/lib64/libthread_db.so.1".
	Game is DarkPlaces-Quake using base gamedir id1
	gamename for server filtering: DarkPlaces-Quake
	DarkPlaces-Quake Linux 18:50:26 Jan 11 2015 - debug
	Current nice level is below the soft limit - cannot use niceness
	Playing shareware version.
	Skeletal animation uses SSE code path
	DPSOFTRAST available (SSE2 instructions detected)
	Failed to init SDL joystick subsystem: 
	couldn't exec quake.rc
	couldn't exec default.cfg
	execing config.cfg
	couldn't exec autoexec.cfg
	Client using an automatically assigned port
	Client opened a socket on address 0.0.0.0:0
	Linked against SDL version 1.2.15
	Using SDL library version 1.2.15

	Breakpoint 1, XInitThreads () at locking.c:573
	573	{
	(gdb) thread apply all bt

	Thread 1 (Thread 0x7ffff7fcc700 (LWP 8884)):
	# 0  XInitThreads () at locking.c:573
	# 1  0x00007fffea173136 in ?? () from /usr/lib64/nvidia/libGL.so.1
	# 2  0x00007fffea1956cd in ?? () from /usr/lib64/nvidia/libGL.so.1
	# 3  0x00007fffea173b9d in ?? () from /usr/lib64/nvidia/libGL.so.1
	# 4  0x00007ffff7deaf0d in call_init (l=0x2923d80, argc=argc@entry=1, argv=argv@entry=0x7fffffffe038, env=env@entry=0x7fffffffe048) at dl-init.c:62
	# 5  0x00007ffff7deb05b in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>, l=<optimized out>) at dl-init.c:34
	# 6  _dl_init (main_map=main_map@entry=0x2923d80, argc=1, argv=0x7fffffffe038, env=0x7fffffffe048) at dl-init.c:124
	# 7  0x00007ffff7defa51 in dl_open_worker (a=a@entry=0x7fffffffcdc8) at dl-open.c:566
	# 8  0x00007ffff7deadf4 in _dl_catch_error (objname=objname@entry=0x7fffffffcdb8, errstring=errstring@entry=0x7fffffffcdc0, mallocedp=mallocedp@entry=0x7fffffffcdb7, 
			operate=operate@entry=0x7ffff7def590 <dl_open_worker>, args=args@entry=0x7fffffffcdc8) at dl-error.c:187
	# 9  0x00007ffff7deeee3 in _dl_open (file=0x7ffff701a7b6 "libGL.so.1", mode=-2147483390, caller_dlopen=0x7ffff6ff968b <X11_GL_LoadLibrary+59>, nsid=-2, argc=<optimized out>, 
			argv=<optimized out>, env=0x7fffffffe048) at dl-open.c:650
	# 10 0x00007ffff725c039 in dlopen_doit (a=a@entry=0x7fffffffcfe0) at dlopen.c:66
	# 11 0x00007ffff7deadf4 in _dl_catch_error (objname=0x292d090, errstring=0x292d098, mallocedp=0x292d088, operate=0x7ffff725bfe0 <dlopen_doit>, args=0x7fffffffcfe0) at dl-error.c:187
	# 12 0x00007ffff725c69d in _dlerror_run (operate=operate@entry=0x7ffff725bfe0 <dlopen_doit>, args=args@entry=0x7fffffffcfe0) at dlerror.c:163
	# 13 0x00007ffff725c0d1 in __dlopen (file=file@entry=0x7ffff701a7b6 "libGL.so.1", mode=mode@entry=258) at dlopen.c:87
	# 14 0x00007ffff6ff968b in X11_GL_LoadLibrary (this=0x2975760, path=0x7ffff701a7b6 "libGL.so.1") at src/video/x11/SDL_x11gl.c:506
	# 15 0x0000000000409616 in VID_InitModeGL (mode=0x7fffffffd4e0) at ../../../vid_sdl.c:2461
	# 16 0x0000000000409cdf in VID_InitMode (mode=0x7fffffffd4e0) at ../../../vid_sdl.c:2758
	# 17 0x00000000006fdbfd in VID_Mode (fullscreen=1, width=640, height=480, bpp=32, refreshrate=60, stereobuffer=0, samples=1) at ../../../vid_shared.c:1857
	# 18 0x00000000006fe4e5 in VID_Start () at ../../../vid_shared.c:2022
	# 19 0x000000000057400c in Host_StartVideo () at ../../../host.c:1088
	# 20 0x000000000047ad16 in SCR_BeginLoadingPlaque (startup=true) at ../../../cl_screen.c:761
	# 21 0x000000000057454b in Host_Init () at ../../../host.c:1324
	# 22 0x0000000000572d99 in Host_Main () at ../../../host.c:679
	# 23 0x000000000040444e in main (argc=1, argv=0x7fffffffe038) at ../../../sys_sdl.c:223

So if a program is written according to the SDL docs and runs with nVidia libGL implementation, the XInitThreads() is called too late from libGL and bad things happen[1]. This problem doesn't occur with SDL 2.0.3 because it calls XInitThreads() during video initialization.

I experience this problem for about 3-6 months now so it's probably caused by change in nVidia proprietary libGL implementation. However, it breaks some packages already present in Fedora which use SDL 1.2. Xonotic is affected for example. The crash happens during closing of the display where libX11 tries to release mutex which is NULL (or some random memory, see [1]).

SDL 1.2 should be patched to explicitly call XInitThreads in SDL_VideoInit() to avoid such crashes under arbitrary libGL implementations.

I wouldn't be able to figure this out without the insight of Xonotic core team wizards, especially divVerent. Thank you.

[1] http://forums.fedoraforum.org/showthread.php?t=302471

Version-Release number of selected component (if applicable): SDL-1.2.15-17.fc21.x86_64

Steps to Reproduce:

1. sudo dnf install xonotic
2. xonotic-sdl
3. # from game UI, either exit the game or change the resolution

Actual results: Game segfaults.

Expected results: Game doesn't segfault.

On 2015-02-01 10:29:56 +0000, wrote:

Whoops. Found the problem. Some time ago, out of curiosity, I put this into my profile.

export __GL_THREADED_OPTIMIZATIONS=1

Removing it or setting it to 0 fixes the problem for me. Sorry for the noise.

On 2015-08-25 09:38:21 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

Our current focus is on SDL 2.0.

If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

Failing that, we will accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

Failing that, please feel free to contact me directly by email ([email protected]) and we'll try to find some way to help you out of your situation.

Thank you, --ryan.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch to address the issue (sdl-fbcon-waitforvsync.patch, text/plain, 2013-05-20 19:04:37 +0000, 624 bytes)

Reported in version: 1.2.15 Reported for operating system, platform: Linux, All

Comments on the original bug report:

On 2013-05-20 19:04:37 +0000, Paul Cercueil wrote:

Created attachment 1145 Patch to address the issue

The fbcon backend uses a non-standard IOCTL to wait for the vertical refresh. The Linux kernel provides a standard IOCTL for that task that should be used instead. See the attached patch.

On 2015-08-25 09:38:22 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

Our current focus is on SDL 2.0.

If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

Failing that, we will accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

Failing that, please feel free to contact me directly by email ([email protected]) and we'll try to find some way to help you out of your situation.

Thank you, --ryan.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Testcase. (testcase.c, text/x-csrc, 2012-03-15 17:20:57 +0000, 508 bytes)
• Patch to fix the delay when closing the ALSA and Pulse drivers. (pulsedelay.patch, text/plain, 2012-03-19 16:37:25 +0000, 3053 bytes)
• SDL 2.0 pulseaudio patch (pulseaudio.patch, text/plain, 2013-11-11 01:21:19 +0000, 1216 bytes)

Reported in version: 1.2.14 Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2012-03-15 17:20:57 +0000, wrote:

Created attachment 838 Testcase.

When SDL_CloseAudio is called on the pulse backend, a delay of around 2 seconds will sometimes occur (about 50% of the time). The rest of the time, the function returns almost immediately. A testcase is attached.

My OS is a fairly vanilla installation of Ubuntu 11.04.

On 2012-03-15 17:40:48 +0000, wrote:

Did a little more testing. Setting the audio driver to alsa rather than pulse has no effect on the bug, presumably because ALSA is emulated as a client of the PulseAudio server. However, setting it to esd removes the bug.

My system has a universal sound latency of around 500ms; I've always presumed it was some sort of driver issue. When terminating the loopwave test with Ctrl+C (using the esd driver), the program will stop running as soon as this latency is over (that is, as soon as sound stops coming out the speakers). Using the pulse and alsa drivers, loopwave will keep running for an additional 1 - 2 seconds beyond this point.

On 2012-03-19 15:43:22 +0000, wrote:

Decided to attempt to fix this bug myself. The delay occurs in SDL_pulseaudio.c, within the call to pa_mainloop_iterate around line 427. This call blocks waiting for completion of an asynchronous pa_stream_drain operation, initiated earlier in the same function.

This bug can be trivially solved by replacing the call to pa_stream_drain with a call to pa_stream_flush, which discards the data rather than waiting for a guarantee that it's finished.

On 2012-03-19 15:47:38 +0000, wrote:

PS: The above fix wouldn't resolve the same problem in the ALSA driver, when ALSA is being emulated on a Pulse system. I haven't tested this, but I believe the issue could be fixed in a similar way by replacing the call to snd_pcm_flush (in ALSA_CloseAudio) with snd_pcm_drop.

On 2012-03-19 16:37:25 +0000, wrote:

Created attachment 839 Patch to fix the delay when closing the ALSA and Pulse drivers.

On 2012-03-19 16:43:19 +0000, wrote:

Sorry for the comment spam, but I forgot to mention: The above patch was generated against the current SDL-1.2 branch of hg. Should also be relevant to SDL2, although I haven't checked that it will apply as-is.

On 2012-03-22 21:24:36 +0000, Ryan C. Gordon wrote:

Is dropping the last buffer of audio the correct approach, though? If you had a music player, should it cut off the last half second of a song so the process can quit quickly?

This bug is real, but I think the culprit is PulseAudio and not SDL:

  http://pulseaudio.org/ticket/866

We mentioned this in Bug # 1013, in regards to SDL_mixer, at one point.

The gist is that we need to tell PulseAudio "wait until you've definitely played what we asked you to and get back to us" and it waits way too long.

I suppose we could work around this in SDL by timing out how long it should take for Pulse to play all our data and just quitting at that point, but that's a goofy solution, too.

--ryan.

On 2012-03-23 15:36:48 +0000, wrote:

Am I right in thinking that patching library or application X to accommodate a difficult-to-fix or widely-deployed bug in library Y isn't usually done in FOSS circles, then? I mean, I'd personally go for the more pragmatic option of patching X, but I can see how that could turn X into a hackjob in the long run.

Philosophical issues aside, though, I'd say that dropping ~500ms of trailing audio will be less harmful in the general case than halting on shutdown for 2s. It's worth noting that without explicitly working around this bug by calling SDL_QuitSubSystem(SDL_INIT_VIDEO) before SDL_CloseAudio, SDL will always close down the audio subsystem before video; therefore, practically all SDL applications that use both audio and video (ie, games) will suffer from an ugly 2-second pause on closing, with an unresponsive window still visible to the user. I haven't tested this broadly, but I can at least confirm that it applies to Frets on Fire.

On 2012-08-06 08:35:35 +0000, Stas Sergeev wrote:

Me too on this bug.

I'd like to note that the problem does NOT depend on how much audio was played and when. For me it pauses for 3 seconds even if SDL_PauseAudio(0) was never called at all, and the sound callback was never called. So I am not sure if the Comment 6 applies well. Or is the PA bug so bad that it hangs even when nothing was played?

On 2013-11-11 01:21:19 +0000, Sam Lantinga wrote:

Created attachment 1415 SDL 2.0 pulseaudio patch

I don't think we actually need to wait for the drain operation to complete. Can you try out this patch and see if it: a) solves your issue b) you actually hear all the audio from the application as it quits?

Thanks!

On 2015-02-16 19:04:15 +0000, Stas Sergeev wrote:

For me the problem no longer happens. I think because of the new pulseaudio-5.0. Tested with SDL-1.2.15 and SDL2-2.0.3 without any patches - all good.

On 2015-08-25 09:38:23 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

Our current focus is on SDL 2.0.

If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

Failing that, we will accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

Failing that, please feel free to contact me directly by email ([email protected]) and we'll try to find some way to help you out of your situation.

Thank you, --ryan.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• ~~Fix bug on Saitek rudder pedals (SDL_mmjoystick.c, application/octet-stream, 2010-08-23 08:58:56 +0000, 11506 bytes)~~
• Updated patch (SDL_mmjoystick.patch, text/plain, 2014-12-12 02:59:45 +0000, 1103 bytes)

Reported in version: 1.2.14 Reported for operating system, platform: Windows (XP), x86

Comments on the original bug report:

On 2010-08-23 08:58:56 +0000, wrote:

Created attachment 536 Fix bug on Saitek rudder pedals

On Saitek ProFlight Rudder Pedals, there are 3 axis detected by SDL (left pedal, right pedal and rotation between the 2 pedals around Z axis). But when rudder is used, SDL updates only values for left and right pedals, rotation value is never changed. This behavior has been seen with SDL 1.2.14 on Windows XP SP 2.

This problem has already been noticed here : http://www.orbiterwiki.org/wiki/FlyByWireEGCS#Saitek_Pro_Flight_Rudder_Pedals http://www.orbiter-forum.com/showthread.php?t=10010

It is not a driver problem, because when I launch driver's test GUI, I can see that all movements are detected.

After some code analysis, I think that I find the problem : MS API sends updated values in JOYINFOEX structure as following (for this rudder device) : dwXpos : left pedal dwYpos : right pedal dwZpos : nothing dwRpos : pedals rotation dwUpos : nothing dwVpos : nothing

There are 3 values but the third one is not at the third position in this structure. So the code seems easy to fix in SDL_mmjoystick.c in SDL_SYS_JoystickUpdate(SDL_Joystick* joystick) function. I attach my own version of this file which has been successfully tested for this device and with some others (on Window XP only).

Hope this can help.

On 2011-04-12 20:18:06 +0000, Jen Spradlin wrote:

Thank you for your bug report!

We're busy working on getting SDL 1.3 ready for a high quality release, and want to make sure as many things are fixed there as possible. Could you check to see if your bug is resolved by the latest SDL 1.3 snapshot? http://www.libsdl.org/tmp/SDL-1.3.zip

Thanks!

On 2011-12-30 01:25:46 +0000, Ryan C. Gordon wrote:

Bumping priority on a few bugs that I would like examined more closely before 1.2.15 is finalized. This is not a promise that a bug will be fixed. We may close it with WONTFIX or WORKSFORME or something, but I just want to make sure attention is paid.

--ryan.

On 2014-12-12 02:59:45 +0000, Kerrigan Bangs wrote:

Created attachment 1967 Updated patch

The original fix by the original reporter did not work for me. I made my own fix.

On 2014-12-12 03:00:22 +0000, Kerrigan Bangs wrote:

I know it's quite late but I know the precise cause of this problem:

The mmjoystick method is written with the assumption that all joystick axes are contiguous.

This is normally true, however apparently the Z axis is allowed to be skipped. (Source: http://msdn.microsoft.com/en-us/library/windows/hardware/ff543445%28v=vs.85%29.aspx at "No Holes" rule)

More recently this problem also affects the Saitek X55 joystick, as its rudder axis is not detected, since the joysticks skips the Throttle axis.

I have attached my own solution as the originally attached fix does not seem to work for me. Also, only the Z axis is allowed to be unmapped, so further checks afterward are not necessary assuming the axis count is correct.

Note that this problem is still present in SDL2, for the mmjoystick method. It doesn't happen in the DX Joystick method. Still, it's easy enough to fix anyways, I think.

On 2015-08-25 09:38:23 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

Our current focus is on SDL 2.0.

If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

Failing that, we will accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

Failing that, please feel free to contact me directly by email ([email protected]) and we'll try to find some way to help you out of your situation.

Thank you, --ryan.

In few places wrong macros are used for Darwin PPC (it follows from code comments that MacOS is meant in those instances). There is no __powerpc__ on Darwin.

Three definitions are there: __ppc__ = ppc32 __ppc64__ = ppc64 __POWERPC__ = ppc32/ppc64

See, for example: https://opensource.apple.com/source/gcc/gcc-5465/gcc/config/rs6000/darwin.h.auto.html (Also, 10.6 does support ppc32.)

issue occured once in the past. please consider it to improve the stability of libsdl.

originally reported here: https://github.com/OpenRA/OpenRA/issues/19027

relevant information:

• Not reproducable
• 99.3% cpu time spent in SDL2.SDL.SDL_GL_DeleteContext
• Using gdb to see the thread is stuck in X11_SafetyNetErrHandler, symbols available
• Browsing the source code (version not checked) http://www-personal.umich.edu/~bazald/l/api/_s_d_l__x11video_8c_source.html
• Relevant source line: https://github.com/libsdl-org/SDL/blob/b5a92406ebd6398e334c88303c2e6c83d3a3f806/src/video/x11/SDL_x11video.c#L136
• Noticing that safety_net_triggered == SDL_TRUE
• Breakpoint shows X11_SafetyNetErrHandler is called continesouly, not recursively
• Noticing that orig_x11_errhandler == X11_SafetyNetErrHandler which results in the callback loop

gdb, display original error handler, which points the same function. (gdb) x orig_x11_errhandler 0x7fc96d8ea220 <X11_SafetyNetErrHandler>: 0x415641f789495741

possible solution/fix/work around:

• SDL should check to see if orig_x11_errhandler does not equal the current function X11_SafetyNetErrHandler
• SDL should check if destroy was called from the same thread as init - if relevant/required

platform:

• Ubuntu 20 LTS. (in the past, with the default latest libSDL of that distribution)

SDL 1.2x apps compiled against SDK 10.15 or SDK 11.x have severe display problems when started on macOS 11. All is fine on macOS < 11.x or when compiled against SDK 10.14. The window is as big as it should be but the actual video display is in the lower left corner, as if it only renders to the lower left quarter of the screen. Observed with DOSBox but reproduced with SDL's testgl program.

It seems that it doesn't matter against which SDK you compiled SDL 1.2x.

Tested with current git and also 5d441412 (as the next commit 718b76b8 added some macOS OpenGL fixes, I thought I'd try the commit before).

Screenshot of testgl compiled against SDK 10.15 on macOS 11

Screenshot of testgl compiled against SDK 10.14 on macOS 11

Edit: with testdyngl, you can see that it really renders to the lower left quarter of the window