Bug 99237

eglGetConfigs() never lists EGLConfigs that point to RGBA X visuals in their EGL_NATIVE_VISUAL_ID attribute. If you create an EGL context and X11 window the "proper" way, i.e. use eglGetConfigs() or eglChooseConfig() and then create a window with the visual noted in the chosen EGLConfig's  EGL_NATIVE_VISUAL_ID attribute, the resulting window's GL-rendered contents will never be alpha-blended by the compositor.

nVidia's EGL implementation on the other hand does list EGLConfigs with RGBA visuals. (They have two almost identical EGLConfigs following each other: first one with a RGB X visual, then with a RGBA one. All fields except EGL_CONFIG_ID and EGL_NATIVE_VISUAL_ID are the same.)

I think that Mesa should do it the same way, and that not doing this is a bug and/or a missing feature that should be added.

Seems like this is done explicitly in dri2_x11_add_configs_for_visuals:
https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_x11.c#n752

First, it allows only 1 config/visual per color class. It really should add two visuals at least for TrueColor visuals (a RGB and then a RGBA one). Second it has some code that explicitly excludes RGBA X visuals, with comments about how applications don't want alpha-composited windows. I'm not completely aware why this can't just be done via the EGL_ALPHA_SIZE attribute (if it's 0, select a RGB-only config), but maybe there are reasons. (Wayland apparently does not care about those reasons, and if you get a RGBA config, your window is always alpha-composited, but I didn't double-check this.) nVidia/EGL and GLX avoid such problems by always listing a config backed by a RGB X visual first.

You could also argue that the API user should just use a RGBA visual when creating the X window, either by completely ignoring the chosen EGLConfig's EGL_NATIVE_VISUAL_ID attribute, or by attempting to select a "compatible" one. However, not all drivers allow using a different X visual (even if it's compatible). The nVidia driver is one such driver. The EGL spec also explicitly states that it's implementation specific whether another underlying pixel format can be used (and mention different X visual IDs as example).

I'm sure application developers should be spared from trying to support both Mesa and nVidia in the hard way by having to implement both methods. While I'm personally less than enchanted for needing platform-specific code in the EGL config selection just to get X11 transparency, nVidia's idea seems to be the best way to implement it. It's similar to how GLX behaves, backwards-compatible, and the application does not need to try to use different visuals for window creation.