Without additional check, even if libOpenGL was loaded, libGL.so will
be loaded as well, and used both in gl_handle and glx_handle, so
libglvnd libraries will not be used.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Throughout the mesa project we've been using 100 for GLES2's shading
language. It was pretty clearly the intent here, but the clever
inline detection of "am I parsing a GLSL version or a GL version
string" forgot about GLSL 1.0.x, and thus returned 10.
When building on macOS we don't have access to EGL, and GLX support is
conditional.
We should ensure we're using the appropriate paths depending on the
platform, and protect our use of macros to avoid undefined symbols.
Closes: #176
We want to consistently handle exceptions for the internal state checks;
calling `exit()` does not allow us to attach a debugger and get a proper
trace.
Now that we're being conservative about probing libraries, these
entrypoints would not succeed unless the caller had already dlopened
stuff themselves, or had explicitly linked against the provider library.
Both of those are exactly not what we want.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Mostly this is to get all the calls to get_dlopen_handle nicely isolated
so they're easier to reason about.
Signed-off-by: Adam Jackson <ajax@redhat.com>
dlsym(NULL) can only see (symbols in) libraries that are loaded
RTLD_GLOBAL, but our dlopen()s are RTLD_LOCAL and probably so was the
one the app did if it did one. So use RTLD_NOLOAD to probe for the
library even if it's LOCAL, iff the lookup is non-fatal.
Having done that, don't ever load any libraries on this path. We only
perform this check while resolving rendering API functions, and the
window system resolution paths already load the appropriate library if
they need to. Since you have to have gone through a winsys to get a
context, and our resolvers only run when a function is _called_, this
would only introduce a failure mode if you tried to call a function
without a context bound.
Signed-off-by: Adam Jackson <ajax@redhat.com>
We're about to change our dlopen paths to do RTLD_NOLOAD more
aggressively. The issue then is we can create an EGL GLES context
without libGLES* ever being loaded. test/egl_gles2_without_glx will fail
in such a world: the first gentle probe for libGLESv2 will fail, then
the less-gentle probe for libGLESv1_CM will be shot down by the test,
and we exit.
Fortunately by the time we've gotten to this point the context exists,
so we can query its version via EGL instead.
Signed-off-by: Adam Jackson <ajax@redhat.com>
The GL version minor numbers haven't hit 10, yet, but if they do we're
going to get non-sensical encoded versions when calling
epoxy_gl_version(), like we're getting right now, with the GLSL version
numbers.
If the minor number is larger than the multiplication factor used for
the major number, we should bump up the factor to the next order of
magnitude.
When building on Android we end up in the Linux branch of the symbol
loading logic, but the __ANDROID__ conditional does not have the
OPENGL_LIB symbol defined, and that breaks the build.
Closes: #152
Epoxy should provide a function that returns the version of the GL
shading language in use, in the same vein as it allows to get the
version of GL.
Closes: #145
Both gcc and clang define __ANDROID__ but not ANDROID when targeting Android so
at least with the Meson build, and an NDK r16 toolchain, testing on
Android failed without this change.
This avoids any unnecessary allocations when simply passing static strings
to be printed onto stderr, and uses the simpler fputs mechanism.
Signed-off-by: Ikey Doherty <ikey@solus-project.com>
The EGL_EXT_device_query extension introduces the
eglQueryDeviceStringEXT() function, which can be used with an
EGLDeviceEXT enumeration to receive an OpenGL extension string
containing all of the device extensions supported by it. From the
EGL_EXT_device_query spec's amendments to section "3.2 Devices" after
"3.1 Errors":
const char *eglQueryDeviceStringEXT(EGLDeviceEXT device,
EGLint name);
returns a pointer to a static, zero-terminated string describing
some aspect of the specified EGLDeviceEXT. <name> must be
EGL_EXTENSIONS.
Since OpenGL extension parsing is rather simple, and we could always run
into additional cases similar to this one in the future, we expose the
shared epoxy_extension_in_string() function in libepoxy's public headers
so that users can save themselves the hassle of having to write their
own extension parser.
Signed-off-by: Lyude Paul <thatslyude@gmail.com>
This code attempts not to dlopen anything if it can find the appropriate
winsys symbols in the global namespace. That's nice. However we normally
do dlopen(RTLD_LOCAL) when we open lib{GLX,EGL} so those symbols will
_not_ in fact be in the global namespace. The code also prefers checking
GLX to EGL, which means even if we initialize EGL through epoxy, and
even if we're using glvnd, we'll still dlopen libGL the first time we
hit epoxy_is_desktop_gl().
There's a couple of ways to skin this cat, let's take the easy one. If
either-but-not-both of the glx or egl handles in the global API state
are initialized, then we know we're already in one or the other. If
neither or both are initialized, then the current heuristic should work
fine.
Note that epoxy_is_desktop_gl() is only bothering to check for GLX to
work around PowerVR's broken GLES. One suspects a better way to do that
would be to check GL_VENDOR or GL_RENDERER and avoid probing the window
system at all.
Signed-off-by: Adam Jackson <ajax@redhat.com>
glvnd has the rather nice property that GLX and (desktop) GL are
available in separate libraries. As an example this would allow an EGL
app to use desktop GL without any X11 libraries. Fix up our dlopens to
prefer the glvnd libraries if available and fall back to the old ABI if
not.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Related commit: b3b8bd9af7
Fix "epoxy_glx_version" to handle the case when GLX is not active on the display.
Patch is tweak from the original version posted by Tom Horsley
When checking whether GLX or EGL are available on the system, we don't
want to use the internal API that forces an exit() on missing libraries
and symbols — as that would defeat the point.
Instead, we should have safe functions to call internally that simply
return a NULL pointer, so we can bail out ourselves in a controlled
fashion.
To avoid a symbols file on Windows, Epoxy annotates all the publicly
visible symbols directly in the source, but uses the default symbol
visibility everywhere else. This means that only some symbols are
annotated as `EPOXY_IMPORTEXPORT`, and generally only on Windows.
Additionally, Epoxy has a private 'PUBLIC' pre-processor macro for
internal use, which duplicates the `EPOXY_IMPORTEXPORT` but contains
more logic to detect GCC, in case we're building with GCC on Windows.
This would be enough, except that EGL is also available on Windows,
which means we'd have to annotate the exported `epoxy_*` API inside
epoxy/egl.h as well. At that point, though, we should probably avoid
any confusion, and adopt a single symbol visibility policy across the
board.
This requires some surgery of the generated and common dispatch sources,
but cuts down the overall complexity:
- there is only one annotation, `EPOXY_PUBLIC`, used everywhere
- the annotation detection is done at Epoxy configuration time
- only annotated symbols are public, on every platform
- annotated symbols are immediately visible from the header
EGL is available on different platforms, so we should favor it, if
available. This also allows us to decouple EGL from GLX, and use the
former without the latter being compiled in.
Binding an API does not change the type of the current context. Even if
it did, EGL 1.5 treats EGL_OPENGL_API and EGL_OPENGLES_API as identical
for this purpose. If you want to know properties of the current
context, query it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Some X server not supporting any OpenGL feature, glXQueryExtensionsString
will return NULL and causes the function to fail.
Thanks to Emmanuel Stapf (manus@eiffel.com) for the original patch.
This was verified running an application on macOS while the X server was
running on Windows Xming 7.5.0.10
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Most of the changes that happened after commit 8bbc0d40 broke epoxy
pretty much irreparably because of the CMake build and the attempt at
making libepoxy a static library that can be copy-pasted into another
project without generating files.
Since all the commits are entangled, and are full of unrelated changes,
we cannot simply do a localized set of reverts; instead, we need to hit
the reset button.
From this point forward, we're going to improve libepoxy's build while
attempting to keep the existing build system working. This may mean
reinstating the CMake build system at a later date.
Binding an API does not change the type of the current context. Even if
it did, EGL 1.5 treats EGL_OPENGL_API and EGL_OPENGLES_API as identical
for this purpose. If you want to know properties of the current
context, query it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
will return NULL and causes the function to fail. Thanx to Emmanuel Stapf (manus@eiffel.com) for the original patch.
This was verified running an application on macOS while the X server was running
on Windows Xming 7.5.0.10