This is an automated email from the git hooks/post-receive script.
git pushed a commit to branch wl/x11-output
in repository enlightenment.
View the commit online.
commit 092c41bf36cfeea25e642faac8fad47f178106c9
Author: Cedric BAIL <[email protected]>
AuthorDate: Thu Aug 13 20:46:14 2026 -0600
wayland - stop calling every non-ARGB8888 buffer opaque
A client's buffer format decides whether e_pixmap says the surface has an
alpha channel, and the switch that decides it listed exactly one layout
that carries alpha: ARGB8888.
Anything else went to the default and was called opaque. That is not a
cosmetic mislabel. e_comp_object hands the answer to evas as the image's
alpha flag, evas_gl_common_image_native_enable() passes it to
evas_gl_common_texture_native_new(), and that picks the texture's internal
format from it - so an alpha-bearing buffer whose format was not in the
list got an RGB texture and had its alpha discarded at allocation time.
Chromium hands us ABGR8888. The result is a client's transparent shadow
margin compositing as solid black: a thick dark border around the browser
window and around every menu it pops up.
Three namespaces arrive in this one switch - a DRM fourcc from dmabuf, a
wl_shm format, an EGL texture format - so each layout has to be listed for
itself. Past its first two entries wl_shm reuses the DRM fourccs verbatim
(WL_SHM_FORMAT_ABGR8888 is 0x34324241, AB24), so one name covers both
spellings of each; only ARGB8888 needs listing twice, since that is one of
the two wl_shm renumbered. Added the 8888 orderings, the four 10-bit ones
and 4444/1555.
This was invisible until now because nothing reached it: dmabuf could not
be imported on gl_x11 at all, so no dmabuf format but the shm ones had ever
been asked about.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01FtoiXoSKUmZb6Aix6U3GZS
---
src/bin/e_pixmap.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/src/bin/e_pixmap.c b/src/bin/e_pixmap.c
index 0c14e569c..bd0787090 100644
--- a/src/bin/e_pixmap.c
+++ b/src/bin/e_pixmap.c
@@ -639,10 +639,36 @@ e_pixmap_refresh(E_Pixmap *cp)
}
else return EINA_FALSE;
+ /* Three namespaces land in this one switch: a DRM fourcc from
+ * dmabuf, a wl_shm format, or an EGL texture format. They do not
+ * collide - wl_shm reuses the DRM fourccs for everything past its
+ * first two entries - but each has to be listed for itself.
+ *
+ * Every layout that carries alpha has to be here, not just
+ * ARGB8888. Chromium hands us ABGR8888. A format missing from
+ * this list is called opaque, and evas then allocates an RGB
+ * texture and drops the alpha channel on the floor, so a client's
+ * transparent shadow margin composites as solid black - a thick
+ * dark border around the window and around every menu it pops. */
switch (format)
{
case DRM_FORMAT_ARGB8888:
case WL_SHM_FORMAT_ARGB8888:
+ /* Past its first two entries wl_shm reuses the DRM fourccs
+ * verbatim - WL_SHM_FORMAT_ABGR8888 is 0x34324241, which is
+ * AB24 - so one name covers the shm and the dmabuf spelling
+ * of each of these. */
+ case WL_SHM_FORMAT_ABGR8888:
+ case WL_SHM_FORMAT_RGBA8888:
+ case WL_SHM_FORMAT_BGRA8888:
+ case WL_SHM_FORMAT_ARGB2101010:
+ case WL_SHM_FORMAT_ABGR2101010:
+ case WL_SHM_FORMAT_RGBA1010102:
+ case WL_SHM_FORMAT_BGRA1010102:
+ case WL_SHM_FORMAT_ARGB4444:
+ case WL_SHM_FORMAT_ABGR4444:
+ case WL_SHM_FORMAT_ARGB1555:
+ case WL_SHM_FORMAT_ABGR1555:
case EGL_TEXTURE_RGBA:
cp->image_argb = EINA_TRUE;
break;
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
