Where is eglGetConfigs getting its configs from?

[Daniel Stone]

Hi Chris,

On Fri, 5 Nov 2021 at 12:01, chris.laplante at agilent.com
<chris.laplante at agilent.com> wrote:
> Can anyone please explain how eglGetConfigs actually works? i.e. what information is it consulting in order to determine the configs to return? Unfortunately we are using a processor (Xilinx Zynq UltraScale) with a GPU (Mali-400 MP2) whose EGL implementation is closed-source. So I cannot look at the source code for eglGetConfigs.

'It depends' is the short and disappointing answer ...

> My expectation was that eglGetConfigs would simply enumerate DRM framebuffers in the system. However, the only framebuffer in our system (a Xilinx Framebuffer Read IP core in the FPGA) is using XRGB8888 colors and the list that Weston reports makes no sense. See below for /var/log/weston.log contents. Some component of the system seems to be finding RGB565 and ARGB8888 framebuffers somewhere.

EGLConfigs are only semi-related to this. Ultimately they do have to
render to a framebuffer for display, however they can be used for
intermediate non-display rendering as well (e.g. FBOs, depth/stencil
buffers). So, the list of EGLConfigs you get is essentially a list of
configurations the GPU is able to render to. A subset of those will be
suitable for display. The mechanism used for selecting a
display-compatible config is to look at the EGL_NATIVE_VISUAL_ID and
match this to a DRM format ...

> [01:36:24.725] Bad/unknown DRM format code 0x00000000.

This is already quite suspicious, since drm_output_init_egl()
shouldn't be passing anything with 0 in the list?

> [01:36:24.725] No EGLConfig matches { win|pbf; XRGB8888 }.

I would also expect to see ARGB8888 in this list ...

>                id:   9 rgba: 8 8 8 8 buf: 32 dep: 24 stcl: 8 int: 0-10 type: win|pix|pbf|swap_preserved vis_id: ARGB8888 (0x34325241)

This is an ARGB8888 config (note the rgba: 8 8 8 8) and the vis_id ...

>                id:  38 rgba: 8 8 8 0 buf: 24 dep: 24 stcl: 8 int: 0-10 type: win|pix|pbf|swap_preserved vis_id: ARGB8888 (0x34325241)

And this is an XRGB8888 config, but incorrectly declared to have a
native visual ID of ARGB8888.

>                id:  41 rgba: 8 8 8 0 buf: 24 dep: 24 stcl: 8 int: 0-10 type: win|pix|pbf|ms_resolve_box|swap_preserved vis_id: ARGB8888 (0x34325241)

These and the following are not relevant as they are multi-sampled
and/or depth/stencil configs.

So, my thoughts are:
  - how do you get to 'Bad/unknown DRM format code 0x00000000' given
that drm_output_init_egl() explicitly prunes the list for this?
  - why is DRM_FORMAT_ARGB8888 not found as a fallback format for
DRM_FORMAT_XRGB8888, given that we should be getting that through
fallback_format_for()?
  - your EGL stack is buggy, because it declares a 8880 format (i.e.
XRGB8888) to be ARGB8888, so fixing that would likely solve the
immediate problem, but the fallbacks above should work

Best of luck.

Cheers,
Daniel