WIP: Add EXT_config_drm_format_query extension

[amshafer]

This extension is a fairly trivial change to allow an application to get the DRM fourcc code for an EGLConfig. In some cases this is desirable, since you may only have an EGLSurface and its config but need to create other resources that match the surface. This can happen with EGLStreams apps or with EGL platform libraries.

From the overview: This extension adds an EGLConfig attribute that specifies a DRM format, as defined in drm_fourcc.h. If an application needs to share buffers with other libraries or processes that require specific formats, then this allows an application to select a matching EGLConfig accordingly. EGLStream applications may need to know what DRM format a surface is using so that they can pass the format and any modifiers to other APIs or other stream consumers.

This extension allows passing EGL_LINUX_DRM_FOURCC_EXT to eglGetConfigAttrib, allowing the application to forward the format code as needed.

[stonesthrow]

This sounds very familiar, like it was proposed before. So, EGLConfig has the EGL_NATIVE_VISUAL_ID to match up with code the Window system/ platform uses. And this extension could use that existing mechanism, and just say EGL_NATIVE_VISUAL_ID contains FourCC codes. BUT on some platforms I think this is already is already in use, and is not available for FourCC code. The back of my brain is tingling that this whole conversation, proposal and comment, happened before. I think it was related to Wayland?

[stonesthrow]

I think this is sounding familiar because of discussions on the proposal for https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_config_select_group.txt

[amshafer]

I know EGL_NATIVE_VISUAL_ID is another case of a query-only attribute for a config, but I do think there's value in keeping this separate. It makes more sense to explicitly ask for a DRM format vs asking for a visual ID that probably is a DRM format. I think it's a better idea for the "already in use" concerns that you outlined.

[kbrenneman]

What EGL_NATIVE_VISUAL_ID is depends entirely on the platform. With EGL_KHR_platform_gbm, it's a fourcc code, but with EGL_KHR_platform_x11, it's the XID for an X Visual.

EGL_KHR_platform_wayland and EGL_EXT_platform_device leave it undefined, so all you can assume is that it's some unique, driver-specific 32-bit value.

[stonesthrow]

Thanks. I'm sure we had this discussion. But that was many context switches ago.

[oddhack]

@stonesthrow this is marked Approved to Merge, but there's still an outstanding change requested by @fooishbar . Can we clear that block before I hit the merge button?

[fooishbar]

@oddhack i want to discuss this further to make it EXT. @cubanismo @kbrenneman if this is time-sensitive then I would prefer it be scoped to Streams only

[amshafer]

Thanks everyone for the feedback, I updated with a new version that specifies this is limited to EGLConfigs which have the EGL_STREAM_BIT_KHR bit set. Does that look like what you all had in mind? I added a very short summary of the discussion in the Issues section to document why it was considered.

Any other changes I should make?

[kbrenneman]

Is a fourcc code meaningful for any consumer type other than EGLImages?

[cubanismo]

Is a fourcc code meaningful for any consumer type other than EGLImages?

I don't think so, but this extension operates on the producer side, so I don't think it should make assumptions about the consumer.

[kbrenneman]

I don't think so, but this extension operates on the producer side, so I don't think it should make assumptions about the consumer.

Tue. I'll admit, putting the fourcc format on the producer side when the format modifiers are on the consumer side does bother me a bit, but I can't think of any other way to do that. If we added EGL_LINUX_DRM_FOURCC_EXT as an attribute for eglCreateImage, then we'd still need something to query a DRM format for the producer so that the color depth can match, and to avoid unnecessary blits.

Anyway, mostly I was wondering whether this should be an EXT extension if it only makes sense in the context of an NV extension.

[fooishbar]

I think the Streams ext now needs to be added to the dependencies section, but the rest lgtm, thanks!

[amshafer]

Updated, thanks!

[cubanismo]

Anyway, mostly I was wondering whether this should be an EXT extension if it only makes sense in the context of an NV extension.

I think as long as no one objects, EXT is preferable to avoid potential awkwardness of any future EXT users depending on an NV. The mechanism seems