The Offscreen video driver is intended to be used for headless rendering
as well as allows for multiple GPUs to be used for headless rendering
Currently only supports EGL (OpenGL / ES) or Framebuffers
Adds a hint to specifiy which EGL device to use: SDL_HINT_EGL_DEVICE
Adds testoffscreen.c which can be used to test the backend out
Disabled by default for now
When using a recent version of CMake (3.14+), this should make it possible to:
- build SDL for iOS, both static and dynamic
- build SDL test apps (as iOS .app bundles)
- generate a working SDL_config.h for iOS (using SDL_config.h.cmake as a basis)
To use, set the following CMake variables when running CMake's configuration stage:
- CMAKE_SYSTEM_NAME=iOS
- CMAKE_OSX_SYSROOT=<SDK> (examples: iphoneos, iphonesimulator, iphoneos12.4, /full/path/to/iPhoneOS.sdk, etc.)
- CMAKE_OSX_ARCHITECTURES=<semicolon-separated list of CPU architectures> (example: "arm64;armv7s")
Examples:
- for Simulator, using the latest, installed SDK:
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64
- for Device, using the latest, installed SDK, 64-bit only
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES=arm64
- for Device, using the latest, installed SDK, mixed 32/64 bit
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES="arm64;armv7s"
- for Device, using a specific SDK revision (iOS 12.4, in this example):
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos12.4 -DCMAKE_OSX_ARCHITECTURES=arm64
- for Simulator, using the latest, installed SDK, and building SDL test apps (as .app bundles):
cmake path/to/SDL -DSDL_TEST=1 -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64
This is currently supported on Linux and macOS. iOS and Android are not
supported at all, Windows support could be added with some changes to the libusb
backend. The Visual Studio and Xcode projects do not use this feature.
Based on Valve Software's hid.cpp, written in collaboration with Andrew Eikum.
add HAVE_ENDPOINTVOLUME_H, HAVE_MMDEVICEAPI_H and HAVE_AUDIOCLIENT_H
in SDL_config.h.in, SDL_config.h.cmake, SDL_config_windows.h, and in
SDL_config_winrt.h.
This isn't complete, but is enough to run testsprite2. It's currently
Mac-only; with a little work to figure out how to properly glue in a Metal
layer to a UIView, this will likely work on iOS, too.
This is only wired up to the configure script right now, and disabled by
default. CMake and Xcode still need their bits filled in as appropriate.
XAudio2 doesn't have capture support, so WASAPI was to replace it; the holdout
was WinRT, which still needed it as its primary audio target until the WASAPI
code code be made to work.
The support matrix now looks like:
WinXP: directsound by default, winmm as a fallback for buggy drivers.
Vista+: WASAPI (directsound and winmm as fallbacks for debugging).
WinRT: WASAPI
Simon Hug
When RWops seeks with fseek or fseeko it uses the types long or off_t which can be 32 bits on some platforms. stdio_seek does not check if the 64-bit integer for the offset fits into a 32-bit integer. Offsets equal or larger than 2 GiB will have implementation-defined behavior and failure states would be very confusing to debug.
The attached patch adds range checking by using the macros from limits.h for long type and some bit shifting for off_t because POSIX couldn't be bothered to specify min and max macros.
It also defines HAVE_FSEEKI64 in SDL_config_windows.h so that the Windows function gets picked up automatically with the default config.
And there's an additional error message for when ftell fails.
Ozkan Sezer
HAVE_LIBSAMPLERATE_H is depending on HAVE_LIBC in current config.h.in:
it shouldn't be. HAVE_LIBUDEV_H, HAVE_DBUS_DBUS_H, HAVE_IBUS_IBUS_H,
HAVE_FCITX_FRONTEND_H, and HAVE_ALTIVEC_H have the same situation too.
I suggest something like the following, which moves them out of the
HAVE_LIBC confinement and also moves the windows dx header stuff along
side them. (Not ideal, but a bit cleaner I think.)
Ozkan Sezer
Cmake checks for float.h, but configure does not: the attached patch
adds float.h to checked headers in configury, and it adds the missing
HAVE_FLOAT_H macro to SDL_config.h.cmake and SDL_config.h.in.
In SDL_config_macosx.h and SDL_config_windows.h, defined HAVE_FLOAT_H
as 1, where I know that it's true.
sfalexrog
Android haptic code was not added to CMakeLists.txt, leading to build failures when targeting Android platform.
Attached patch adds Android haptic driver to source sets and adds configuration parameter to SDL_config.h.cmake.
manuel.montezelo
Original bug report (note that it was against 2.0.0, it might have been fixed in between): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733015
--------------------------------------------------------
Package: libsdl2-2.0-0
Version: 2.0.0+dfsg1-3
Severity: normal
Tags: patch
I have occasional crashes here caused by the X11 backend of SDL2. It seems to
be caused by the X11_Pending function trying to add a high number (> 1024)
file descriptor to a fd_set before doing a select on it to avoid busy waiting
on X11 events. This causes a buffer overflow because the file descriptor is
larger (or equal) than the limit FD_SETSIZE.
Attached is a possible workaround patch.
Please also keep in mind that fd_set are also used in following files which
may have similar problems.
src/audio/bsd/SDL_bsdaudio.c
src/audio/paudio/SDL_paudio.c
src/audio/qsa/SDL_qsa_audio.c
src/audio/sun/SDL_sunaudio.c
src/joystick/linux/SDL_sysjoystick.c
--------------------------------------------------------
On Tuesday 24 December 2013 00:43:13 Sven Eckelmann wrote:
> I have occasional crashes here caused by the X11 backend of SDL2. It seems
> to be caused by the X11_Pending function trying to add a high number (>
> 1024) file descriptor to a fd_set before doing a select on it to avoid busy
> waiting on X11 events. This causes a buffer overflow because the file
> descriptor is larger (or equal) than the limit FD_SETSIZE.
I personally experienced this problem while hacking on the python bindings
package for SDL2 [1] (while doing make runtest). But it easier to reproduce in
a smaller, synthetic testcase.
Juha Niemim?
On AmigaOS 4 platform with Newlib 'C' library, there is a problem with failing fseeko64. This seemed to be caused by using fopen instead of fopen64.
Manuel
The attached patch adds support for KMS/DRM context graphics.
It builds with no problem on X86_64 GNU/Linux systems, provided the needed libraries are present, and on ARM GNU/Linux systems that have KMS/DRM support and a GLES2 implementation.
Tested on Raspberry Pi: KMS/DRM is what the Raspberry Pi will use as default in the near future, once the propietary DispmanX API by Broadcom is overtaken by open graphics stack, it's possible to boot current Raspbian system in KMS mode by adding "dtoverlay=vc4-kms-v3d" to config.txt on Raspbian's boot partition.
X86 systems use KMS right away in every current GNU/Linux system.
Simple build instructions:
$./autogen.sh
$./configure --enable-video-kmsdrm
$make
Ozkan Sezer
(In reply to Ryan C. Gordon from comment #9)
> I've put this patch in as https://hg.libsdl.org/SDL/rev/7213ae46e870 ...can
> you verify this works on the latest MinGW?
>
> Thanks,
> --ryan.
This patch is wrong: the structure in question has nothing to do with any
gcc version in use. I suggest reverting this adding a conigury check for
it, instead. Something like the following should do it: (configure needs
regenerating.)
Kai Sterker
SDL2 on Haiku so far uses Haiku-specific APIs for loading dynamic objects as add-ons, instead of using dlopen to load them as libraries. This, for example, leads to SDL_mixer not being able to load its audio backends, when compiled with standard settings.
As discussed at https://www.freelists.org/post/haikuports/SDL2-mixer-ogg-music-not-playing-and-other-stuff,2 , the best way to deal with this would be using dlopen instead of load_add_on. The following patch implements this change by dropping the Haiku-specific bits and using dlopen instead.
joe.gsoc16
I recently looked into Unicode support in SDL2 and realized that
SDL_TEXTEDITING doesn't get triggered at all (Japanese IME).
According to others on IRC it works fine on Windows/Mac but not
for me on (arch)Linux.
When compiling SDL with autotools, IBus support is enabled by
default but not so with CMake.
I never used CMake before but got it working and also included
that pkg-config determines flags for dbus (FIXME in CMakeLists).
The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly
uninitialized data structure if loading the library first failed. A later try to
use EGL then skipped initialization and assumed it was previously successful
because the data structure now already existed. This led to at least one crash
in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was
dereferenced to make a call to eglBindAPI().
