This is an automated email from the git hooks/post-receive script.
git pushed a commit to branch wl/browser-all
in repository enlightenment.
View the commit online.
commit 82cdb2780ffe459e994459bdbc624d23061fa4f9
Author: Cedric BAIL <[email protected]>
AuthorDate: Mon Aug 17 16:34:58 2026 -0600
e_comp_x - report GL from the canvas we got, not the engines we could build
e_comp_x_randr_canvas_new() sets the compositor-wide GL flag from
ecore_evas_engine_type_supported_get(OPENGL_X11) - a question about how
EFL was built, asked before any canvas exists. That is a precondition for
attempting GL, not a result of having obtained it, and the only place it
was ever corrected is the software fallback, which is inside
"if (!e_comp->ee)" and so does not run when a canvas already exists.
The result is a compositor that reports itself accelerated while running
on software_x11. Measured on the wl_x11 backend: engine 'software_x11',
e_comp->gl 0, e_comp_gl_get() 1. e_comp_wl_init() believes the flag and
runs the Evas_GL setup against the software canvas, which hands back an
api table with every EGL entry NULL - evasglQueryDmaBufFormats,
evasglQueryDmaBufModifiers and evasglBindWaylandDisplay among them. With
the last of those NULL, e_comp->gl is never set for the wayland side
either, so there is no GL path for client buffers at all: no dmabuf, and
every client falls back to shm without anything saying why.
e_comp->gl already holds the right answer - it is set where a GL canvas
is actually created - so the flag is now taken from it at the end of the
function, once, whichever branch ran.
---
src/bin/e_comp_x_randr.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/src/bin/e_comp_x_randr.c b/src/bin/e_comp_x_randr.c
index e7a3b8bc3..c9cc6288c 100644
--- a/src/bin/e_comp_x_randr.c
+++ b/src/bin/e_comp_x_randr.c
@@ -1279,6 +1279,27 @@ e_comp_x_randr_canvas_new(Ecore_Window parent, int w, int h)
elm_config_all_flush();
elm_config_save();
}
+ /* Whatever happened above, the flag has to describe the canvas that now
+ * exists rather than the engines this build could have used.
+ *
+ * The check at the top of this function asks ecore_evas whether it
+ * *supports* OPENGL_X11, which is a question about how EFL was built, and
+ * sets the flag from the answer. That is a precondition for trying GL, not
+ * a result of having got it - but the only place it was ever corrected is
+ * the software fallback below, and that whole block is skipped when
+ * e_comp->ee already exists. A caller who arrives here with a canvas
+ * already made therefore leaves with the flag saying GL no matter what the
+ * canvas is.
+ *
+ * On the wl_x11 backend that is exactly what happens: the compositor comes
+ * up on software_x11 with e_comp->gl correctly 0, while e_comp_gl_get()
+ * answers 1. e_comp_wl_init() believes it, runs the Evas_GL setup against a
+ * software canvas, and gets an api table with every EGL entry NULL -
+ * including evasglBindWaylandDisplay, so E has no GL path for client
+ * buffers at all and no dmabuf, while still reporting itself as
+ * accelerated. */
+ e_comp_gl_set(!!e_comp->gl);
+
if (ret)
e_comp->grab_cb = _e_comp_x_randr_grab_cb;
return ret;
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
