SDL 2.0.9 prerelease

Thanks to all the people who contributed code and feedback, SDL 2.0.9 is now available as a PRERELEASE build!

In addition to lots of bug fixes and build improvements, here are the major changes in this release:

  • Added a new sensor API, initialized by passing SDL_INIT_SENSOR to SDL_Init(), and defined in SDL_sensor.h
  • Added an event SDL_SENSORUPDATE which is sent when a sensor is updated
  • Added SDL_GetDisplayOrientation() to return the current display orientation
  • Added an event SDL_DISPLAYEVENT which is sent when the display orientation changes
  • Added HIDAPI joystick drivers for more consistent support for Xbox, PS4 and Nintendo Switch Pro controller support across platforms. (Thanks to Valve for contributing the PS4 and Nintendo Switch Pro controller support)
  • Added support for many other popular game controllers
  • Added SDL_GameControllerRumble() and SDL_JoystickRumble() which allow simple rumble without using the haptics API
  • Added SDL_GameControllerMappingForDeviceIndex() to get the mapping for a controller before it’s opened
  • Added the hint SDL_HINT_MOUSE_DOUBLE_CLICK_TIME to control the mouse double-click time
  • Added the hint SDL_HINT_MOUSE_DOUBLE_CLICK_RADIUS to control the mouse double-click radius, in pixels
  • Added SDL_HasColorKey() to return whether a surface has a colorkey active
  • Added SDL_HasAVX512F() to return whether the CPU has AVX-512F features
  • Added SDL_IsTablet() to return whether the application is running on a tablet
  • Added SDL_THREAD_PRIORITY_TIME_CRITICAL for threads that must run at the highest priority

Mac OS X:

  • Fixed black screen at start on Mac OS X Mojave


  • Added SDL_LinuxSetThreadPriority() to allow adjusting the thread priority of native threads using RealtimeKit if available.


  • Fixed Asian IME input


  • Updated required Android SDK to API 26, to match Google’s new App Store requirements
  • Added support for wired USB Xbox, PS4, and Nintendo Switch Pro controllers
  • Added support for relative mouse mode on Android 7.0 and newer (except where it’s broken, on Chromebooks and when in DeX mode with Samsung Experience 9.0)
  • Added support for custom mouse cursors on Android 7.0 and newer
  • Added the hint SDL_HINT_ANDROID_TRAP_BACK_BUTTON to control whether the back button will back out of the app (the default) or be passed to the application as SDL_SCANCODE_AC_BACK
  • Added SDL_AndroidBackButton() to trigger the Android system back button behavior when handling the back button in the application
  • Added SDL_IsChromebook() to return whether the app is running in the Chromebook Android runtime
  • Added SDL_IsDeXMode() to return whether the app is running while docked in the Samsung DeX

Can I assume that a SDL_WINDOWEVENT_RESIZED event will also be sent in these circumstances, as was previously the case (unless the display happens to be square!)?

Shouldn’t the default be to maintain compatibility with earlier versions of SDL, i.e. to pass SDLK_AC_BACK to the application?

1 Like

I got this build error only when I enable video-mir:

In file included from /usr/include/mirclient/mir_toolkit/events/input/input_event.h:26:0,
                 from /usr/include/mirclient/mir_toolkit/events/event.h:91,
                 from /usr/include/mirclient/mir_toolkit/client_types.h:24,
                 from ***/SDL2-2.0.9/src/joystick/../events/../video/./khronos/vulkan/./vk_platform.h:101,
                 from ***/SDL2-2.0.9/src/joystick/../events/../video/./khronos/vulkan/vulkan.h:31,
                 from ***/SDL2-2.0.9/src/joystick/../events/../video/SDL_vulkan_internal.h:61,
                 from ***/SDL2-2.0.9/src/joystick/../events/../video/SDL_sysvideo.h:30,
                 from ***/SDL2-2.0.9/src/joystick/../events/SDL_events_c.h:26,
                 from ***/SDL2-2.0.9/src/joystick/SDL_joystick.c:33:
***/SDL2-2.0.9/src/joystick/controller_type.h:28:16: error: expected identifier before numeric constant
typedef enum { false, true } bool;

Values of the enum seem to be used only in a commented out assert in SDL_joystick.c line 1518 and the enum itself is only used one function in controller_type.h. Including SDL_stdinc.h and replacing bool by SDL_bool fixe the problem.

Then the mir headers are somehow including stdbool.h which defines false and true to numeric values.

Solution should be replacing those bool stuff with SDL_bool.

I pushed to the hg repo: should fix that boolean issue.

1 Like

Hi folks, new here but have an issue showing up with the 2.0.9 pre release that you might be able to help with.

I’ve been using SDL2 for about 3 years on a hobby OS project called ChrysaLisp,, and after an upgrade from High Sierra to Mojave I had problems building and running.

Now I saw the issue about the black screen on startup problem, and saw the fix for that was in the pre-release 2.0.9 so I’ve tried that, but no joy.

What I can tell you is that using the 2.0.9 pre-release compiled on High Sierra the resulting executable will work fine on Mojave ! Both using the 2.0.9 or 2.0.8 in the frameworks folder.

But if I compile on Mojave then the app launches and I only ever see a full red window. I know my OS is running inside that window via various debug outputs, but I never see anything but full red screen.

Running ‘otool -L’ on the exe I can see that the only difference is the stdlib dylib version number. Clearly the code may be different due to the Mojave compiler etc.

A small example code in C I tried to just do a simple filled rectangle test does work, compiled on Mojave. So this has left me a little puzzled.

I know that ChrysaLisp is far removed from your normal C/C++ applications as it’s uses it own assembler and compiler and Lisp, but things have been working fine up till this point. And the fact that the version compiled on High Sierra works fine on both is interesting.

Full source and build instructions are up on Github, only takes 2 seconds (literally) to do a build and try it out if anyone would care to investigate with me. I’m stumped after a whole day looking into it, so time to call in the SDL experts.

Regards to all


Additional info. I just thought to try the Mojave executable, that shows red screen only, on High Serra (luckily I didn’t yet upgrade my older MacBbook !) and lo, it runs fine over there !

So that eliminates any issue with the code produced by the Mojave compiler clang difference as the cause and points at the difference in the stdlib dylib !

This is the output of otool -l on the main exe’s.

High Sierra built:

@rpath/SDL2.framework/Versions/A/SDL2 (compatibility version 1.0.0, current version 10.0.0)
@rpath/SDL2_ttf.framework/Versions/A/SDL2_ttf (compatibility version 15.0.0, current version 15.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)

Mojave built:

@rpath/SDL2.framework/Versions/A/SDL2 (compatibility version 1.0.0, current version 10.0.0)
@rpath/SDL2_ttf.framework/Versions/A/SDL2_ttf (compatibility version 15.0.0, current version 15.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)



Awesome, I’ve been testing the default branch on macOS 10.14 and Ubuntu 18.04.1. Everything looking good except I’m having problems initializing the sensor module. I’m compiling with a standard ./configure && make && sudo make install, and the module says it’s enabled, but SDL_Init(SDL_INIT_EVERYTHING) is failing with SDL_GetError() returning "SDL not built with sensor support". I even tried rebuilding with --enable-sensor with no luck. SDL_Init(SDL_INIT_SENSOR) also reports the same error. I can’t find anything abnormal in the build system, but I’ll keep looking.

@slouken Just saw your commit (231245d461a2), pulled and retested. Works great, thanks! :+1:

Great, thanks for checking!

Will be interesting to see how all the HIDAPI stuff pans out!

There are a couple things I’m still concerned about in other parts of SDL, but thankfully they’re all really small and have patches:

#1. WASAPI is extremely fussy and expects a specific update period size, and if SDL doesn’t allow programs to find this, it can sometimes be problematic if the update sizes vary too much. The SDL_AudioStream fallback covers most cases, but not all, and I dunno if that’s something AudioStream can fix, so for us the easiest fix is SDL_AUDIO_ALLOW_SAMPLES_CHANGE:

For Xbox in particular this is definitely a must-have. Right now FAudio is doing this, and it’s as stable as it looks:

#2. Haptic magnitude ranges aren’t consistent across platforms; on Linux it expects 0-65535 when everyone else wants 0-32768. There’s a patch and I think it might still apply cleanly after the HIDAPI stuff, but even then it’s a whopping 5 lines…

Without this, programs have to do something like this:

3. Resize events and size change events are capable of conflicting each other if they happen within the same frame; it’s unlikely in the surface-level case (user resizes the window at the exact same time they hit “OK” in a video settings menu?!) but some very subtle cases like toggling SDL_WINDOW_FULLSCREEN_DESKTOP actually run into OS resize events that can conflict with a program’s size change events. Again, there’s a patch and it’s pretty small:

Without that, you basically have to ignore OS resizes or risk having your viewport get screwed up. In FNA we have this check, which is also as nice as it looks:

4. Android really likes stubbing functions instead of saying they’re not supported, so for debug contexts we sometimes run into scenarios where ARB_debug_output isn’t supported, and their debug printf gets interpreted as an error and the context creation fails instead of just rejecting the one flag. Maik patched this but it’s a Git patch, not a Hg patch, though it’s relatively small either way:

Without this we’re basically screwed and have to either disable debugging on all Android builds or edit the FNA source every time we want to switch between debug and not debug, depending on the device in question. That said, this probably borders on “hack for a hack” so I dunno if there’s a better route for this.

Apologies for the super long post but I wanted to be sure these got looked at before the official tag. I’m subscribed to all of these bugs so we can use those for discussion to avoid getting sidetracked.


Has 2.0.9 taken account of the several ‘The key you just pressed is not recognized by SDL’ reports posted here? I suspect that these reports don’t result in formal bugs being filed, and I wouldn’t want them to be forgotten.

@vygr, I see a lot of docs up on ChrysaLisp’s Github site, but at a glance, I am unsure how to build and run it in a way, that demonstrates this bug.

Might you be able to either point to some specific steps that demonstrate building + running ChrysaLisp and reproducing this bug, or better, provide a short, concise, C or C++ app that demos this issue (using SDL 2.0.9)?

If you move the window, does it start rendering?

Sad to see that WASAPI will most likely still be broken in 2.0.9, which is not good because it’s the default for SDL2 on Windows. It’s completely useless for some people because it can have random buffer problems when using the callback.

I have never understood why WASAPI is the default. In my app I have:

#ifdef __WINDOWS__
	SDL_setenv("SDL_AUDIODRIVER", "directsound", 1);

Can I expect this to fail in any circumstances?

It can fail if directsound is not available, though I can’t think of any scenario where it wouldn’t.
In my programs I scan through the available drivers (#ifdef _WIN32) to select directsound if it’s available, if not then I try winmm. If that fails too, I go for WASAPI after all (yuck).

EDIT: Checked my sources, I was a bit wrong, edited the post.

1 Like

Can anyone confirm it’s working on Android 4.2.2 (possibly all pre-Kitkat versions)? I’m getting a run-time error about missing libs. Trying to find more info before posting more…

No, that was the first thing I tried :slight_smile:

1 Like

Hi David, thanks for the interest.

A quick build and setup intro is in the doc/ file, well worth a read.

However, if you have your SDL frameworks installed on MacOS you should be able to just clone the repo, go into the folder, and type ‘make’.

Now this will currently use a version of the High Sierra ‘main’ bootstrap and create a main-d which is the actual version you just compiled.

With the High Sierra version of main, running ./ (launch the GUI) should work fine. If you look in the Makefile you will see the line where it creates ‘$@-d’, switch that back to say ‘$@’ and re-make with ‘make’ and relaunch with ./ and you should see the non working GUI. This is assuming your building on Mojave.

Makefile line 16:
cc -o $@-d $@.o -F/Library/Frameworks -Wl,-framework,SDL2 -Wl,-framework,SDL2_ttf
Change back to:
cc -o $@ $@.o -F/Library/Frameworks -Wl,-framework,SDL2 -Wl,-framework,SDL2_ttf

I only get the none working situation with the compiled on Mojave, run on Mojave. Both versions work on High Sierra and the High Sierra version works fine on Mojave.

The place where the window gets setup and the renderer is created is in the file gui/gui/class.vp starting at line 98.