This is an automated email from the git hooks/post-receive script.
git pushed a commit to branch fix-release-build
in repository efl.
View the commit online.
commit 1e1b94d11aacbb923f1d44515e688cac3cc8212d
Author: Cedric BAIL <[email protected]>
AuthorDate: Thu Aug 6 22:40:32 2026 -0600
ecore_evas/drm: don't require libglapi for the gl_drm engine
Mesa 25.1 folded libglapi into libgallium and stopped shipping
libglapi.so.0. We dlopen()ed it and bailed out when dlerror() was set,
so on every mesa >= 25.1 system ecore_evas_gl_drm_new() returned NULL -
with nothing logged at all. Enlightenment then quietly fell back to the
software drm engine and spun forever in evas_render_rendering_wait().
The dlopen() was only there so the GL dispatch symbols were visible to
the dlsym(RTLD_DEFAULT, "gl*") lookups in gl_common; libEGL pulls the
dispatch in either way, so the library going missing is harmless. Keep
trying it for older stacks where it really is a separate object, but
never treat its absence as fatal.
dlerror() was the wrong test regardless - it also reports errors left
over from unrelated earlier dlopen()s. Check the handle instead.
While here, log the engine lookup failure in _ecore_evas_new_internal()
rather than returning NULL mutely, since callers read that as "use the
software engine instead" and the reason was getting lost.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
---
.../ecore_evas/engines/drm/ecore_evas_drm.c | 28 ++++++++++++++++++----
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c b/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
index c024e6322c..a1ece1305a 100644
--- a/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
+++ b/src/modules/ecore_evas/engines/drm/ecore_evas_drm.c
@@ -1003,7 +1003,13 @@ _ecore_evas_new_internal(const char *device, int x, int y, int w, int h, Eina_Bo
else
method = evas_render_method_lookup("drm");
- if (!method) return NULL;
+ /* Callers treat NULL as "try the software engine instead", so failing
+ * mutely here just moves the confusion downstream - say why. */
+ if (!method)
+ {
+ ERR("Evas engine '%s' is unavailable", gl ? "gl_drm" : "drm");
+ return NULL;
+ }
ee = calloc(1, sizeof(Ecore_Evas));
if (!ee) return NULL;
@@ -1147,10 +1153,24 @@ ecore_evas_drm_new_internal(const char *device, unsigned int parent EINA_UNUSED,
EMODAPI Ecore_Evas *
ecore_evas_gl_drm_new_internal(const char *device, unsigned int parent EINA_UNUSED, int x, int y, int w, int h)
{
- static void *libglapi = NULL;
+ static Eina_Bool tried = EINA_FALSE;
- if (!libglapi) libglapi = dlopen("libglapi.so.0", RTLD_LAZY | RTLD_GLOBAL);
- if (dlerror()) return NULL;
+ /* We used to force-load libglapi so the GL dispatch symbols were visible
+ * to the dlsym(RTLD_DEFAULT, "gl*") lookups gl_common does. Mesa 25.1
+ * folded libglapi into libgallium and stopped shipping it, so it being
+ * missing is now the normal case and must not be fatal - libEGL brings
+ * the dispatch in either way. Still try it for older stacks where it
+ * really is a separate object.
+ * NB: dlerror() is not a reliable failure test here. It also reports
+ * errors left over from unrelated earlier dlopen()s, which is how this
+ * turned into a silent "no GL for you" on every mesa >= 25.1 system. */
+ if (!tried)
+ {
+ tried = EINA_TRUE;
+ if (!dlopen("libglapi.so.0", RTLD_LAZY | RTLD_GLOBAL))
+ DBG("libglapi.so.0 unavailable (expected on mesa >= 25.1): %s",
+ dlerror());
+ }
return _ecore_evas_new_internal(device, x, y, w, h, EINA_TRUE);
}
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
