Giovanni Bajo
The CMake build system supports several audio frameworks for Linux: one of them is sndio.
All frameworks can be built with "runtime linking" (that is, using dlopen to load the library at runtime). In sdlchecks.cmake, there's code to do the same with sndio:
=================================================================
# Requires:
# - n/a
# Optional:
# - SNDIO_SHARED opt
# - HAVE_DLOPEN opt
macro(CheckSNDIO)
if(SNDIO)
# TODO: set include paths properly, so the sndio headers are found
check_include_file(sndio.h HAVE_SNDIO_H)
find_library(D_SNDIO_LIB sndio)
if(HAVE_SNDIO_H AND D_SNDIO_LIB)
set(HAVE_SNDIO TRUE)
file(GLOB SNDIO_SOURCES ${SDL2_SOURCE_DIR}/src/audio/sndio/*.c)
set(SOURCE_FILES ${SOURCE_FILES} ${SNDIO_SOURCES})
set(SDL_AUDIO_DRIVER_SNDIO 1)
if(SNDIO_SHARED)
if(NOT HAVE_DLOPEN)
message_warn("You must have SDL_LoadObject() support for dynamic sndio loading")
else()
FindLibraryAndSONAME("sndio")
set(SDL_AUDIO_DRIVER_SNDIO_DYNAMIC "\"${SNDIO_LIB_SONAME}\"")
set(HAVE_SNDIO_SHARED TRUE)
endif()
else()
list(APPEND EXTRA_LIBS ${D_SNDIO_LIB})
endif()
set(HAVE_SDL_AUDIO TRUE)
endif()
endif()
endmacro()
=================================================================
The feature is gated by an option called SNDIO_SHARED. It is also fully implemented in SDL_sndioaudio.c
Unfortunately, it seems there is a missing line in CMakeLists.txt, so SNDIO_SHARED is not defined:
======================================================================
set_option(ALSA "Support the ALSA audio API" ${UNIX_SYS})
dep_option(ALSA_SHARED "Dynamically load ALSA audio support" ON "ALSA" OFF)
set_option(JACK "Support the JACK audio API" ${UNIX_SYS})
dep_option(JACK_SHARED "Dynamically load JACK audio support" ON "JACK" OFF)
set_option(ESD "Support the Enlightened Sound Daemon" ${UNIX_SYS})
dep_option(ESD_SHARED "Dynamically load ESD audio support" ON "ESD" OFF)
set_option(PULSEAUDIO "Use PulseAudio" ${UNIX_SYS})
dep_option(PULSEAUDIO_SHARED "Dynamically load PulseAudio support" ON "PULSEAUDIO" OFF)
set_option(ARTS "Support the Analog Real Time Synthesizer" ${UNIX_SYS})
dep_option(ARTS_SHARED "Dynamically load aRts audio support" ON "ARTS" OFF)
set_option(NAS "Support the NAS audio API" ${UNIX_SYS})
set_option(NAS_SHARED "Dynamically load NAS audio API" ${UNIX_SYS})
set_option(SNDIO "Support the sndio audio API" ${UNIX_SYS})
set_option(FUSIONSOUND "Use FusionSound audio driver" OFF)
dep_option(FUSIONSOUND_SHARED "Dynamically load fusionsound audio support" ON "FUSIONSOUND" OFF)
======================================================================
You can see that all frameworks define a "dep_option" NAME_SHARED, and SNDIO is the only one where the option is missing.
This means that runtime loading of sndio is never activated. If sndio is found at configuration time, it is always activated in "linked" mode, so that the final binary will have a load-time dependency with libsdnio. This is unfortunate.
To fix the problem, it is sufficient to add this line:
dep_option(SNDIO_SHARED "Dynamically load the sndio audio API" ${UNIX_SYS} ON "SNDIO" OFF)
I've verified that this fixes the bug, and sndio can now be dynamically loaded as expected.
It currently behaves like a locking key which is pressed
when Caps Lock is enabled and released when disabled. This
means that apps that trigger events on Caps Lock key down will
only fire these events every other time Caps Lock is pressed.
Lacky
It looks like refactoring of SDL2 internal API has broken SDL_RenderFillRect for DirectFB. In new version function SDL_RenderFillRect returns 0, but rectangle is not visible.
Replacing "count" with "len" in the argument list for SDL_memcpy in DirectFB_QueueFillRects fixes problem.
Jan Bujak
I wrote a new driver for my gamepad on Linux. I'd like SDL to support it out-of-box, as currently it just treats it as a generic joystick instead of a gamepad. From what I can see the only way to do that is to either 1) pick one of the already supported controllers' PID, VID and button layouts and have my driver send that (effectively lying that it's something else), or 2) submit a preconfigured, hardcoded mapping to SDL.
Both of those, in my opinion, are silly when we already have the Linux Gamepad Specification which standarizes this:
https://www.kernel.org/doc/html/v4.15/input/gamepad.html
Unfortunately SDL doesn't make use of it currently. So I've took it upon myself to add it; patch is in the attachments.
Basically what the patch does is that if SDL finds no built-it controller mappings for a given joystick it then asks the joystick backend to autodetect it, and that uses the relevant evdev bits to figure out which button/axis is which. (See the specs for more details.)
With this patch applied my own driver for my controller works out-of-box with SDL with no extra configuration and is correctly recognized as a gamepad; this is also going to be the case for any other driver which follows the Linux Gamepad Specification.
Arithmatic operations promote Uint8 to signed int. If the top bit of a
Uint8 is set, and it is left shifted 24 places, then the result is not
representable in a signed 32 bit int. This would be undefined behaviour
on systems where int is 32 bits.
It makes it clearer who owns the memory, and more reasonable to free it on
failure in the creating function.
(and, of course, pacifies static analysis.)
Manuel Alfayate Corchete
On the KMSDRM backend, there is no such thing as a desktop, yet some programs could (and DO) use SDL_GetGlobalMouseState().
So I think its good idea that, in KMSDRM, it returns the same mouse coordinates anyway as SDL_GetMouseState() would return. There is nothing else it could return, as far as I can understand, since there is no desktop anyway.
This small patch does precisely that.
Manuel Alfayate Corchete
The KMSDRM backend was doing things wrong because of some small (but important) misconceptions on how KMS/DRM works: to implement a largely broken non-vsync refresh mechanism, the SwapWindow() function was issuing new pageflips before previous ones had completed, thus causing EBUSY returns, buffer mismanagement, etc... resulting in general breakage on vsync disabling from apps, that would not allow vsync to work again without KMSDRM video re-initialization.
To further clarify, on most DRM drivers async pageflips are NOT working nowadays, so all issued pageflips will complete on next VBLANK, NOT ASAP (calling drmModePageFlip() with the DRM_MODE_PAGE_FLIP_ASYNC flag will return error).
The old code was assuming that can just issue a synchronous (=on VBLANK) pageflip and then pass a 0 timeout to the pull() function so we do not wait for the pageflip event, thinking that this will lead to correct non-vsynced screen updates from the program: That is plain wrong.
Each pageflip has to be waite before issuing a new one, ALWAYS. And if we do not support ASYNC pageflips on the DRM driver level, then we are forced to wait for the next VBLANK. There is no way around it.
I have also added many comments on the KMSDRM code. This is needed for future reference for me or others who may need to look at this code: KMS/DRM terminology regarding what SYNC and ASYNC mean in pageflip terms, and where to do certain things and why, is not trivial. It is not desirable or possible to invest time on researching the same concepts every time there is need to dive into this code. So please leave all these comments in the patch.
1. Comment that SDL_SetThreadPriority will make any necessary system changes when applying priority.
2. Add a hint to override SDL's default behavior for scheduler policy.
3. Modify the pthreads SDL_SetThreadPriority so that instead of just using the current thread scheduler policy it will change it to a policy that should work best for the requested priority.
4. Add hint checks in SDL_SetThreadPriority so that #3 can be overridden if desired.
5. Modify the Linux SDL_SetThreadPriority so that in the case that policy, either by SDL defaults or from the hint, is a realtime policy it uses the realtime rtkit API.
6. Prior to calling rtkit on Linux make the necessary thread state changes that rtkit requires. Currently this is done every time as it isn't expected that SDL_SetThreadPriority will be called repeatedly for a thread.
The compiler understands it, but the "qcc" compiler driver doesn't, and the
standard Khronos headers upset QNX anyhow, since they try to include X11
headers in the __unix__ section.
