mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-05-19 02:48:07 +02:00
For some reason that I don't yet fully understand, Glaze does not work with libEGL unless libEGL is linked with -Bsymbolic.[*] Beyond that specific reason, all of the reasons for which libGL.so is linked with -Bsymbolic, (see the commit history), should also apply here. [*] The specific behavior I am seeing is that when Glaze calls dlopen for libEGL.so, ifunc resolvers within Glaze for EGL functions are called before the dlopen returns. These resolvers cannot succeed, as they need the return value from dlopen in order to find the functions to resolve to. I don't know what's causing these resolvers to be called, but I have verified that linking libEGL with -Bsymbolic causes this problematic behavior to stop. CC: "9.1 and 9.2" <mesa-stable@lists.freedesktop.org> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Chad Versace <chad.versace@linux.intel.com> |
||
|---|---|---|
| .. | ||
| Android.mk | ||
| egl.def | ||
| egl.pc.in | ||
| eglapi.c | ||
| eglapi.h | ||
| eglarray.c | ||
| eglarray.h | ||
| eglcompiler.h | ||
| eglconfig.c | ||
| eglconfig.h | ||
| eglcontext.c | ||
| eglcontext.h | ||
| eglcurrent.c | ||
| eglcurrent.h | ||
| egldefines.h | ||
| egldisplay.c | ||
| egldisplay.h | ||
| egldriver.c | ||
| egldriver.h | ||
| eglfallbacks.c | ||
| eglglobals.c | ||
| eglglobals.h | ||
| eglimage.c | ||
| eglimage.h | ||
| egllog.c | ||
| egllog.h | ||
| eglmisc.c | ||
| eglmisc.h | ||
| eglmode.c | ||
| eglmode.h | ||
| eglmutex.h | ||
| eglscreen.c | ||
| eglscreen.h | ||
| eglstring.c | ||
| eglstring.h | ||
| eglsurface.c | ||
| eglsurface.h | ||
| eglsync.c | ||
| eglsync.h | ||
| egltypedefs.h | ||
| Makefile.am | ||
| README.txt | ||
| SConscript | ||
Notes about the EGL library: The EGL code here basically consists of two things: 1. An EGL API dispatcher. This directly routes all the eglFooBar() API calls into driver-specific functions. 2. Fallbacks for EGL API functions. A driver _could_ implement all the EGL API calls from scratch. But in many cases, the fallbacks provided in libEGL (such as eglChooseConfig()) will do the job. Bootstrapping: When the apps calls eglOpenDisplay() a device driver is selected and loaded (look for dlsym() or LoadLibrary() in egldriver.c). The driver's _eglMain() function is then called. This driver function allocates, initializes and returns a new _EGLDriver object (usually a subclass of that type). As part of initialization, the dispatch table in _EGLDriver->API must be populated with all the EGL entrypoints. Typically, _eglInitDriverFallbacks() can be used to plug in default/fallback functions. Some functions like driver->API.Initialize and driver->API.Terminate _must_ be implemented with driver-specific code (no default/fallback function is possible). A bit later, the app will call eglInitialize(). This will get routed to the driver->API.Initialize() function. Any additional driver initialization that wasn't done in _eglMain() should be done at this point. Typically, this will involve setting up visual configs, etc. Special Functions: Certain EGL functions _must_ be implemented by the driver. This includes: eglCreateContext eglCreateWindowSurface eglCreatePixmapSurface eglCreatePBufferSurface eglMakeCurrent eglSwapBuffers Most of the EGLConfig-related functions can be implemented with the defaults/fallbacks. Same thing for the eglGet/Query functions. Teardown: When eglTerminate() is called, the driver->API.Terminate() function is called. The driver should clean up after itself. eglTerminate() will then close/unload the driver (shared library). Subclassing: The internal libEGL data structures such as _EGLDisplay, _EGLContext, _EGLSurface, etc should be considered base classes from which drivers will derive subclasses.