This is handled in in the higher-level SDL_GL_LoadLibrary().
All uses of SDL_EGL_LoadLibrary (which calls the Only version) are just
target-specific wrappers for their own GL_LoadLibrary hook, with two
exceptions which now handle driver_loaded correctly (although it's
questionable if these init-if-no-one-did-it-correctly-already code blocks
should exist at all, fwiw).
Fixes Bugzilla #5190.
On Raspberry Pi 3 via the VC4 driver in firmware KMS mode, none of the
found configs match the desired format, causing the function to fall through
without any config being selected.
Fix by first iterating over the found configs, and if no match exists,
don't exclude the non-matching configs. This should fix RPI3 and possibly other
targets without breaking targets that have a matching native format (such as RPI4).
This allows you to bind surfaceless contexts on a background thread to, for
example, load assets in a separate context, for platforms that have different
requirements about sharing surfaces, etc.
Martin's notes on the matter:
"Here's a patch that enables passing NULL windows to SDL_GL_MakeCurrent, if
the involved APIs allow it. Currently, this is only the case for EGL, and
even then only if some specific extensions are present (which they usually
are).
If "surfaceless" contexts are not supported, SDL_GL_MakeCurrent continues to
generate an error (albeit with a more specific error message than it used to),
so this should not break anything that wasn't broken before."
(Please see https://bugzilla.libsdl.org/show_bug.cgi?id=3695 for more
discussion.)
Fixes Bugzilla #3695.
This results in a dlsym() call, which causes Emscripten to panic if the game
wasn't explicitly built dlopen support. eglGetProcAddress works just fine on
this platform, so just let that codepath handle it.
Use eglGetProcAddress for everything on EGL >= 1.5. Try SDL_LoadFunction first
for EGL <= 1.4 in case it's a core symbol, and as a fallback if
eglGetProcAddress fails. Finally, for EGL <= 1.4, fallback to
eglGetProcAddress to catch extensions not exported from the shared library.
(Maybe) Fixes Bugzilla #4794.
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
Rainer Sabelka
After I did an upgrade of my arch Linux installation (resulting in an update of Mesa to version 18.2.3), all my SDL2 applications which use the KMS/DRM driver stopped working.
Reason: Creating a Window with SDL_CreateWindow failed because the call to EGL
eglCreateWindowSurface() returns an error "EGL_BAD_MATCH".
After investigating with the debugger I figured, that the configuration, which has been selected from the output of eglChooseConfig(), has an "EGL_NATIVE_VISUAL_ID" which does not match the "format" of the underlying gbm surface.
The attached patch fixes the problem. It does so, by mimicking Weston's behavior.
All configurations returned from eglChooseConfig() which have an visual_id different from the gbm format are discarded, and only from the remaining ones the "best" match is selected.
If we change the current context behind the app's back, those tracking
the current context to minimize context changes are going to get
confused.
This brings the EGL backend in line with the GLX one.
Fixes Bugzilla #4199.
SDL now builds with gcc 7.2 with the following command line options:
-Wall -pedantic-errors -Wno-deprecated-declarations -Wno-overlength-strings --std=c99
The EGL_GL_COLORSPACE_KHR is an attribute for eglCreate*Surface.
As written in EGL_KHR_gl_colorspace documentation:
Accepted as an attribute name by eglCreateWindowSurface,
eglCreatePbufferSurface and eglCreatePixmapSurface
EGL_GL_COLORSPACE_KHR 0x309D
(...)
Andrey
Seems latest google angle library successfully built & tested under macOS'es.
https://github.com/google/angle
We need to use GLES2 to implement true cross-platform code.
tomwardio
Proposed patch loads eglCreatePbufferSurface in same manner as other 1.1 functors. This allows custom video drivers to create pbuffer surfaces.
tomwardio
Add support to be able to set EGL_SURFACE_TYPE bits when creating an EGL config. This is usefule when wanting to create pixel buffer surfaces in custom video drivers.
Now we try the new (hardware-specific) pathnames first, and if those fail to
load, we'll try the more generic names that earlier versions of Raspbian used.
Fixes Bugzilla #3800.
Carlos
We would like to add a switch (define) that allows us to compile Angle statically with SDL. That is, getting rid of the OpenGL DLL. Usually you need OpenGL to be loaded dynamically as DLL because implementation is provided by the system but no need with Angle.
Only 2 files need modification and it shouldn't affect current behaivor:
include/SDL_egl.h and src/video/SDL_egl.c, as in here
https://github.com/native-toolkit/sdl/pull/10/files
The flag name could be SDL_VIDEO_STATIC_ANGLE (instead of NATIVE_TOOLKIT_STATIC_ANGLE) as discussed here https://github.com/native-toolkit/sdl/pull/10
We have tested this with both Windows and UWP, using NME engine (https://github.com/haxenme/nme).
Releated issue: https://bugzilla.libsdl.org/show_bug.cgi?id=1820
Simon Hug
Some code in SDL loads libraries with SDL_LoadObject to get more information or use newer APIs. SDL_LoadObject may fail, set an error message and SDL will continue with some fallback code. Since SDL will overwrite the error or exit the function with a return value that indicates success, the error form SDL_LoadObject for the optional stuff might as well be cleared right away.