khronosgroup / egl-registry Goto Github PK

#43 made eglplatform.h include X11 headers on APPLE platforms. Unfortunately this breaks building Chrome because these headers are not readily available. Also note that the PowerVR SDK has been using int type for EGLNativeDisplayType (0 to indicate the default display), and NSView* for EGLNativeWindowType (cast to void*), since at least 2010.

So I don't think EGL should suddenly demand using X11 on Mac OS X. @1ace can we make it optional? Something like USE_X11, similar to the existing USE_OZONE, would work for us. Open to other suggestions.

The DocBook description of this function seems to have experienced an editing error in the last spec update. Its first sentence currently reads

If surface is a back-buffered window surface, eglSwapBuffers then the color buffer is copied (posted) native window associated with that surface.

which is not grammatical. For comparison, the EGL 1.5 PDF specification (specs/eglspec.1.5.pdf) reads

If surface is a back-buffered window surface, then the color buffer is copied
to the native window associated with that surface.

which makes much more sense.

How should a driver handle device unplug when it supports EXT_device_enumeration?

• Should the EGLDevice handles of the unplugged device remain valid?
• When is it safe from a driver to invalidate an EGLDevice handle (and release associated resources)?
• What happens when trying to use the unplugged EGLDevice?

This issue stems from https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/215. We need to be careful to pick behavior that is compatible with a vendor-neutral EGL loader such as glvnd.

For instance, it's not safe for a driver to invalidate an unplugged EGLDevice after the EGL client calls eglQueryDevicesEXT, because that would allow another driver to re-use the exact same handle and prevent the EGL client from figuring out the EGLDevice is gone or has changed. Or maybe glvnd should wrap vendor EGLDevices to prevent this?

cc @cubanismo @kbrenneman

EXT_image_dma_buf_import allows one to import DMA-BUFs, but doesn't allow one to enumerate the list of supported formats. EXT_image_dma_buf_import_modifiers fixes this by adding eglQueryDmaBufFormatsEXT.

The ability to enumerate formats is key for proper format negotiation, e.g. in a Wayland compositor. The latest linux-dmabuf protocol version doesn't allow clients to import DMA-BUFs for formats not advertised by the compositor.

Some drivers don't support modifiers. Because format enumeration is important, Mesa will still advertise EXT_image_dma_buf_import_modifiers for these drivers (and return an empty list in eglQueryDmaBufModifiersEXT).

But none of this is documented anywhere. It would be nice to settle on a solution and add it to the EGL specs. Here are two possible proposals:

1. Document that drivers supporting EXT_image_dma_buf_import should also support EXT_image_dma_buf_import_modifiers even if they don't support modifiers.
2. Add a new EXT_image_dma_buf_import_formats extension, which is a subset of EXT_image_dma_buf_import_modifiers: it would contain only eglQueryDmaBufFormatsEXT but not eglQueryDmaBufModifiersEXT. Slightly more work, but if it makes sense to you I'm willing to send patches around.

Thoughts?

cc @cubanismo @fooishbar

As far as I can tell these entry points are new in EGL 1.5 (folded in from the EGL_EXT_platform_base extension in 1.4). The eglGetPlatformDisplay correctly mention that it's new in 1.5, but neither the eglCreatePlatformWindowSurface nor eglCreatePlatformPixmapSurface docs do (instead they somewhat-misleadingly document some of their accepted parameter values as new in 1.5).

I can prepare a PR to update the docs if I've understood this correctly.

It seems there's currently no cross-vendor EGL display timing / presentation timing extension(s) available for Linux.

The lack of EGL display timing extensions has come up for example when Firefox was adding support for Wayland, and thus moving from GLX to EGL (https://bugzilla.mozilla.org/show_bug.cgi?id=1640779), and also when SDL was adding Wayland support ( libsdl-org/SDL#4306 (comment) , https://gitlab.freedesktop.org/mesa/mesa/-/issues/4932 ). Both projects obviously motivated by trying to support both X11 and Wayland with a single EGL code path.

for GLX / X11 there's for example these commonly used extensions:

• "GLX_SGI_video_sync": https://www.khronos.org/registry/OpenGL/extensions/SGI/GLX_SGI_video_sync.txt
• "GLX_OML_sync_control": https://www.khronos.org/registry/OpenGL/extensions/OML/GLX_OML_sync_control.txt

for EGL there's:

• "EGL_CHROMIUM_sync_control": https://chromium.googlesource.com/chromium/src/gpu/+/refs/heads/main/GLES2/extensions/CHROMIUM/EGL_CHROMIUM_sync_control.txt (also: #115), but EGL_CHROMIUM_sync_control is currently implemented only in Mesa afaik, so for example Nvidia Linux driver does not implement it.
• "EGL_ANGLE_sync_control_rate": https://www.khronos.org/registry/EGL/extensions/ANGLE/EGL_ANGLE_sync_control_rate.txt , which is implemented in Mesa (but not in Nvidia proprietary drivers).
• "EGL_ANDROID_presentation_time": https://www.khronos.org/registry/EGL/extensions/ANDROID/EGL_ANDROID_presentation_time.txt , but that's obviously Android-only/specific.

Thus I'm opening this issue here in EGL-Registry for discussion about how to get some EGL display timing extension to be available in all the commonly used Linux drivers, in a cross-vendor fashion.

For reference: work-in-progress Vulkan "VK_EXT_present_timing extension": KhronosGroup/Vulkan-Docs#1364

It seems for some reason "EGL_ANGLE_sync_control_rate" extension is missing from the registry. Specification is available at https://chromium.googlesource.com/chromium/src/gpu/+/master/GLES2/extensions/ANGLE/EGL_ANGLE_sync_control_rate.txt

Work is ongoing to implement EGL_ANGLE_sync_control_rate in Mesa (issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2930 , mr: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5139 ).

Firefox is currently planning to start using EGL_ANGLE_sync_control_rate with the (recently introduced) EGL/X11 backend ( https://bugzilla.mozilla.org/show_bug.cgi?id=1640779 ).

Is there a reason why the eglplatform.h in this repository diverged from the MESA eglplatform.h

Most notable difference is probably, that the Khronos eglplatform.h is missing Wayland.

Differences:

--- khronos_eglplatform.h       2018-03-09 21:37:58.658488640 +0100
+++ mesa_eglplatform.h  2018-03-09 21:44:49.643770693 +0100
@@ -77,12 +77,24 @@
 typedef HBITMAP EGLNativePixmapType;
 typedef HWND    EGLNativeWindowType;
 
-#elif defined(__APPLE__) || defined(__WINSCW__) || defined(__SYMBIAN32__)  /* Symbian */
+#elif defined(__WINSCW__) || defined(__SYMBIAN32__)  /* Symbian */
 
 typedef int   EGLNativeDisplayType;
 typedef void *EGLNativeWindowType;
 typedef void *EGLNativePixmapType;
 
+#elif defined(WL_EGL_PLATFORM)
+
+typedef struct wl_display     *EGLNativeDisplayType;
+typedef struct wl_egl_pixmap  *EGLNativePixmapType;
+typedef struct wl_egl_window  *EGLNativeWindowType;
+
+#elif defined(__GBM__)
+
+typedef struct gbm_device  *EGLNativeDisplayType;
+typedef struct gbm_bo      *EGLNativePixmapType;
+typedef void               *EGLNativeWindowType;
+
 #elif defined(__ANDROID__) || defined(ANDROID)
 
 struct ANativeWindow;
@@ -92,13 +104,15 @@
 typedef struct egl_native_pixmap_t*     EGLNativePixmapType;
 typedef void*                           EGLNativeDisplayType;
 
-#elif defined(USE_OZONE)
+#elif defined(__unix__) || defined(__APPLE__)
 
-typedef intptr_t EGLNativeDisplayType;
-typedef intptr_t EGLNativeWindowType;
-typedef intptr_t EGLNativePixmapType;
+#if defined(MESA_EGL_NO_X11_HEADERS)
 
-#elif defined(__unix__)
+typedef void            *EGLNativeDisplayType;
+typedef khronos_uintptr_t EGLNativePixmapType;
+typedef khronos_uintptr_t EGLNativeWindowType;
+
+#else
 
 /* X11 (tentative)  */
 #include <X11/Xlib.h>
@@ -108,6 +122,14 @@
 typedef Pixmap   EGLNativePixmapType;
 typedef Window   EGLNativeWindowType;
 
+#endif /* MESA_EGL_NO_X11_HEADERS */
+
+#elif __HAIKU__
+#include <kernel/image.h>
+typedef void                           *EGLNativeDisplayType;
+typedef khronos_uintptr_t       EGLNativePixmapType;
+typedef khronos_uintptr_t       EGLNativeWindowType;
+
 #else
 #error "Platform not recognized"
 #endif

https://github.com/KhronosGroup/OpenGL-Registry.git

It seems for some reason "EGL_CHROMIUM_sync_control" extension is missing from the registry. Specification is available at https://chromium.googlesource.com/chromium/src/gpu/+/master/GLES2/extensions/CHROMIUM/EGL_CHROMIUM_sync_control.txt

At least Mesa implements EGL_CHROMIUM_sync_control extension since 2014, and for example Firefox is planning to start using it with the (recently introduced) EGL/X11 backend (https://bugzilla.mozilla.org/show_bug.cgi?id=1640779). Chromium afaik already uses it. There are probably other users aswell.

Hi,

The EGL-Registry page at:
https://github.com/KhronosGroup/EGL-Registry/blob/master/README.md
mention that:
"
In the past, the EGL registry was maintained in a public Subversion repository. The history in that repository has not been imported to github, but it is still available at https://cvs.khronos.org/svn/repos/registry/trunk/public/egl/ .
"

When clicking on the svn link, I get a login popup. I do have a Khronos user account. When entering my credentials, I get a HTTP 403 forbidden error. Not entering credentials gives a HTTP 401 unauthorized error.

For info, with my Khronos account, I can still navigate in the registry trunk:
https://cvs.khronos.org/svn/repos/registry/trunk/

How can I access to the older EGL Registry history?

Thanks!

Julien.

This arises from a mesa issue found here: https://gitlab.freedesktop.org/mesa/mesa/issues/2080

In the situation where the OpenGL command stream contains

eglCreateSyncKHR(EGL_SYNC_NATIVE_FENCE_ANDROID);
glClear(); // i.e. do some work
eglCreateSyncKHR(EGL_SYNC_NATIVE_FENCE_ANDROID);

and is flushed, when the first native fence is extracted, the radeonsi mesa driver returns a native fence from the previous submission rather than creating a new one. This leads to surprising results when we extract the timestamp from this fence (using Linux-specific APIs).

From the spec:

When a fence sync object is created or when an EGL native fence sync object is created with the EGL_SYNC_NATIVE_FENCE_FD_ANDROID attribute set to EGL_NO_NATIVE_FENCE_FD_ANDROID, eglCreateSyncKHR also inserts a fence command into the command stream of the bound client API's current context (i.e., the context returned by eglGetCurrentContext), and associates it with the newly created sync object.

To me, this would imply that a new native fence is created and is signalled when the GPU reaches that point in the OpenGL command stream, assuming that what what a "fence command" means.

But it was argued that this is not what a fence command is, and it is really just telling the driver to fetch the fence from the last batch of work that was completed:
https://gitlab.freedesktop.org/mesa/mesa/issues/2080#note_289275

Is radeonsi's behaviour conformant to this specification and my understanding is wrong? Is the spec not worded precisely enough, and should it be changed to clarify it?

In the EGL 1.5 spec, there's a couple minor typos in the description of eglGetCurrentSurface on page 62:

In the line:

If there is no current context for the current rendering API, then EGL_NO_SURFACE is returned (this is not an error).

That should probably say "If there is no current surface," since in EGL 1.5 you're allowed to have a current context without a current surface.

On the same page, the error description says eglGetCurrentContext where it should say eglGetCurrentSurface, and is missing a period at the end of the first sentence:

Errors
eglGetCurrentContext returns EGL_NO_SURFACE on failure (but may
also return it if no context is bound, as described above)
If readdraw is neither EGL_READ nor EGL_DRAW , an EGL_BAD_-
PARAMETER error is generated.

Referenced EGL_EXT_gl_colorspace_bt2020_pq instead of EGL_EXT_gl_colorspace_display_p3.

EGL_EXT_image_dma_buf_import has a number of hints:

        EGL_YUV_COLOR_SPACE_HINT_EXT    0x327B
        EGL_SAMPLE_RANGE_HINT_EXT       0x327C
        EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT  0x327D
        EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT    0x327E

However there is no way for an EGL client to figure out which hints will be taken into account by the driver, and which will be ignored. It would be nice to allow EGL clients to query this information.

Ref https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/153

Somehow we appear to have managed to register both EGL_KHR_display_reference and EGL_EXT_colorspace_display_p3 as extension 118

Noticed this when I was adding missing extensions to the webpage in PR #40

On QNX, __unix__ is also defined. Since the __unix__ block appears before the __QNX__ block, the Unix native types are chosen rather than the QNX native types. The __QNX__ block needs to precede the __unix__ block.

The __QNX__ block also needs to precede the WL_EGL_PLATFORM block. The existence of WL_EGL_PLATFORM doesn't necessarily indicate that Wayland is the native window platform. It only indicates that Wayland is a supported platform. For QNX, QNX Screen is currently the native window platform but Wayland may also be a window platform (accessed via eglGetPlatformDisplay, et al).

Really, it would be better if the native window platform was explicitly defined rather than being guessed. But that's probably something that can't be changed at this point.

EGL 1.4 reference pages, eglChooseConfig:

The alpha mask buffer is used only by OpenGL and OpenGL ES client APIs.

EGL 1.4 specification, page 17:

The alpha mask buffer is used only by OpenVG.

Which one is it? 😛

Hi,

I've not found any other place to report this, hope this is the correct one. I've been trying to get ahold of the persons of contact for the following extensions:

but both addresses bounce back. My contacts have also been unable to supply me with alternative points of contact.

Would it be possible to update the extensions' RFCs with up-to-date details?

In the EGL 1.5 spec, the semantics of the EGLContext handle returned by eglCreateContext isn't clear with regard to a context that's been marked for deletion. Specifically, if a context is marked for deletion but still current, then is eglCreateContext allowed to return the same EGLContext handle as the deleted context?

For example, in this sequence:

EGLContext ctx1 = eglCreateContext(dpy, config, NULL, NULL);
eglMakeCurrent(dpy, surf, surf, ctx1);
eglDestroyContext(dpy, ctx1);
EGLContext ctx2 = eglCreateContext(dpy, config, NULL, NULL);
assert(ctx2 != ctx1);

Is it valid behavior for that assert to fail?

My initial reading was that it should not fail, based on this reasoning:

• When eglDestroyContext is called, if the context is current to any thread, then the context is marked for deletion, but is not destroyed until it is no longer current to any thread.
• An EGLContext handle corresponds to exactly one context until that context is destroyed
• eglCreateContext can't return the same EGLContext handle as a deleted but current, because then the handle would correspond to a different context, while the original context still exists

That second point is the question. The spec (EGL 1.5, section 3.2) says that after being deleted, EGLContext handles are "invalid", but it's not clear whether the EGLContext handle is freed and can be re-used for a new context, or if it means that the EGLContext handle still exists but you can't pass the handle to any functions.

From a practical standpoint, reusing an EGLContext handle seems like it has some ugly implications. The context is still current as far as any OpenGL calls are concerned, and eglGetCurrentContext will probably return the same (now deleted) context handle, especially if the context was current to a different thread than the thread which called eglDestroyContext. That means that eglGetCurrentContext could return a valid EGLContext handle that does not match the current context.

We are developing a color-management Wayland protocol extension, and expect EGL implementations to use it on behalf of the application, because EGL already defines the extensions to do so. We need to define the rules how that works in EGL_KHR_platform_wayland.

The relevant existing extensions that should feed into color-management are:

• EXT_gl_colorspace_bt2020
• EXT_gl_colorspace_scrgb_linear
• EXT_gl_colorspace_display_p3
• EXT_gl_colorspace_display_p3_passthrough
• EXT_gl_colorspace_scrgb
• EXT_surface_SMPTE2086_metadata
• EXT_surface_CTA861_3_metadata

Most of these extensions work by defining new values for EGL_GL_COLORSPACE EGLSurface attribute. These extension values are clear how they should map to color-management. The EGL extensions assume that the values are forwarded to and used by the platform, that is, the window system.

The base values (defined by EGL 1.5) are not obvious how they should work though, especially the default being EGL_GL_COLORSPACE_LINEAR¹. Without color-management protocol extension, Wayland cannot handle "linear color", that is, optically encoded stimulus. Hence, no application has ever actually provided "linear color" on Wayland, and I doubt they did that on any other platform either because the usual 8 bits per color channel is not enough precision for dark shades. The color-management protocol is perfectly capable of communicating optically encoded stimulus, but mapping EGL_GL_COLORSPACE_LINEAR to that would likely break all existing EGL Wayland applications.

In order to preserve the behavior of existing applications, the use of EGL_GL_COLORSPACE_LINEAR must result in EGL not setting any "image description" on the Wayland surface with color-management protocol extension. Probably EGL_GL_COLORSPACE_SRGB needs to do the same. Wayland compositors will handle such Wayland surfaces appropriately, given that it is needed for backward compatibility of any Wayland application not using color-management protocol.

This also means that using EGL API, it is not possible to tell the Wayland window system that the surface is explicitly sRGB.

We also need to guarantee a way to use EGL on a wl_surface such that the application itself, not EGL, drives the color-management Wayland extension. The Wayland extension supports more than EGL API exposes, particularly the use of ICC profiles. Defining EGL_GL_COLORSPACE_LINEAR and EGL_GL_COLORSPACE_SRGB settings to not create a wp_color_management_surface_v1 on EGL Wayland platform achieves that.

The above needs to be documented in EGL_KHR_platform_wayland.

On this page (https://www.khronos.org/registry/EGL/sdk/docs/man/html/start.html) the link to eglIntro (https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglIntro.html) is broken.

https://github.com/http-party/http-server/actions/workflows/stale.yml

For eglCreatePlatformWindowSurface the attribute EGL_GL_COLORSPACE default value is EGL_GL_COLORSPACE_LINEAR in the pdf reference, but EGL_GL_COLORSPACE_SRGB in the web reference.

• https://www.khronos.org/registry/EGL/specs/eglspec.1.5.pdf
• https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglCreatePlatformWindowSurface.xhtml

The APIs signature states that it receives external_win_id as input -

EGLBoolean eglCompositorSwapPolicyEXT(EGLint external_win_id, EGLint policy);

While the API description itself mentions external_ref_id as input -

This function shall be called by the primary context to specify the handling of buffer swaps of the context specified by external_ref_id.

With the extension EGL_EXT_create_context_robustness 1, it is possible to specify the reset notification strategy of a context by adding two fields in the attribute list when using eglCreateContext.

Unfortunately, it is not possible to query the reset notification strategy of a given context. When trying to get the EGL_CONTEXT_OPENGL_RESET_NOTIFICATION_STRATEGY_EXT with eglQueryContext, EGL_BAD_ATTRIBUTE is returned, despite the requested attribute being valid.

This comes in the way when trying to create a shared context of a context with a specific reset notification strategy. From the EGL_EXT_create_context_robustness spec changes:

  If the reset notification behavior of <share_context> and the
  newly created context are different then an EGL_BAD_MATCH error is
  generated.

Is this an implementation details, and Mesa (the driver I am using) could returns the correct value instead of EGL_BAD_ATTRIBUTE, or is this a whole in the spec waiting to be defined and improved?

I'm trying to share a cubemap texture between two processes using
DMABUFs.

The current approach, using EGLImage, imples the creation of 6 EGLImage
representing the 6 faces of the cubemap, making 6 distinct DMA-BUF.

Reassembling the cubemap on the other process (see 1) doesn't seems to be
doable for the moment, so I'd like to discuss about extending the API to
generate an EGLImage in a single DMABUF for cubemap textures.

Discussions on the #dri-devel IRC channel pointed out that this is
theoritically possible, but that the current DMABUF api doesn't allow it.

I believe extending the EGL_KHR_gl_texture_cubemap_image extension to
add a EGL_GL_TEXTURE_CUBE_MAP target would be a start.

Forgive me if this came up in the initial extension proposal discussion, which I have not found.

The spec says the default is platform-dependent, but then goes ahead and demands what the platforms should do:

Interactions with EGL_KHR_platform_android:

    If eglGetPlatformDisplay() is called with <platform> set to
    EGL_PLATFORM_ANDROID_KHR, the default value of
    EGL_TRACK_REFERENCES_KHR is EGL_TRUE.

Interactions with EGL_EXT_platform_device, EGL_KHR_platform_gbm,
EGL_KHR_platform_x11, and EGL_KHR_platform_wayland:

    If eglGetPlatformDisplay() is called with <platform> set to
    EGL_PLATFORM_DEVICE_EXT, EGL_PLATFORM_GBM_KHR, EGL_PLATFORM_X11_KHR,
    or EGL_PLATFORM_WAYLAND_KHR, the default value of
    EGL_TRACK_REFERENCES_KHR is EGL_FALSE.

Is this really necessary? I don't especially like the non-refcounted behavior, I can't imagine a universe where you'd want it, and would prefer Mesa not do it. And I could make it do that, but then I'd need to not expose EGL_KHR_display_reference on (for example) X11 displays, which would mean the app would have no way to query what the EGL will do. Seems like it might be cleaner to just delete the explicit platform interaction text and emphasize that the default is not merely platform but implementation dependent.

The link from https://www.khronos.org/registry/EGL/ gives a 404 for EGL_EXT_gl_colorspace_display_p3*. The spec text as a "EGL_" prefix, but the URL doesn't.'

@courtney-g, @oddhack

Noticed this had not been done yet.

The first run of the Android app on emulator is OK. But after ghranting permission from user to access to the particular activity the emulator craches with the following logs:
3:30 PM Emulator: queryCoreProfileSupport: swap interval not found

In Android bug report I found :

05-13 13:28:46.486 1456 1456 I SurfaceFlinger: EGL information:
05-13 13:28:46.486 1456 1456 I SurfaceFlinger: vendor : Android
05-13 13:28:46.486 1456 1456 I SurfaceFlinger: version : 1.4 Android META-EGL
05-13 13:28:46.486 1456 1456 I SurfaceFlinger: extensions: EGL_KHR_get_all_proc_addresses EGL_ANDROID_presentation_time EGL_KHR_swap_buffers_with_damage EGL_ANDROID_get_native_client_buffer EGL_ANDROID_front_buffer_auto_refresh EGL_ANDROID_get_frame_timestamps EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_fence_sync EGL_ANDROID_image_native_buffer EGL_ANDROID_recordable
05-13 13:28:46.486 1456 1456 I SurfaceFlinger: Client API: OpenGL_ES
05-13 13:28:46.486 1456 1456 I SurfaceFlinger: EGLSurface: 8-8-8-8, config=0x2
05-13 13:28:46.487 1456 1456 D EGL_emulation: eglCreateContext: 0xb1820960: maj 2 min 0 rcv 2

I can rerun the emulator only after clearing up all emulator's data ( Tools->AVD Manage ->Wipe Data)

video controller data:

lspci|grep VGA
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
sudo lshw -C video

*-display UNCLAIMED
description: 3D controller
product: GM107M [GeForce GTX 960M]
vendor: NVIDIA Corporation
physical id: 0
bus info: pci@0000:01:00.0
version: a2
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list
configuration: latency=0
resources: memory:de000000-deffffff memory:c0000000-cfffffff memory:d0000000-d1ffffff ioport:e000(size=128) memory:df000000-df07ffff
*-display
description: VGA compatible controller
product: HD Graphics 530
vendor: Intel Corporation
physical id: 2
bus info: pci@0000:00:02.0
version: 06
width: 64 bits
clock: 33MHz
capabilities: pciexpress msi pm vga_controller bus_master cap_list rom
configuration: driver=i915 latency=0
resources: irq:129 memory:dd000000-ddffffff memory:b0000000-bfffffff ioport:f000(size=64) memory:c0000-dffff

related issues are mentioned here:
https://stackoverflow.com/questions/25281224/android-setswapinterval-interval-1-not-set-when-try-to-open-new-window
https://stackoverflow.com/questions/16285546/glfwswapinterval1-fails-to-enable-vsync

https://community.nxp.com/thread/378756
thus, it may contain more than one item. In my case, I was getting the error: "Failed to choose config, error = EGL_SUCCESS". By changing the line below:
if (!eglChooseConfig(mEglDisplay, attribs, &mEglConfig, num_configs, &num_configs) || num_

Hello, I was checking what extensions were supported on my machine and I got the following list by printing the output of eglQueryString(EGL_NO_DISPLAY, EGL_EXTENSIONS):

EGL_EXT_platform_base 
EGL_EXT_device_base 
EGL_EXT_device_enumeration 
EGL_EXT_device_query 
EGL_KHR_client_get_all_proc_addresses 
EGL_EXT_client_extensions 
EGL_KHR_debug 
EGL_KHR_platform_x11 
EGL_EXT_platform_x11 
EGL_EXT_platform_device 
EGL_KHR_platform_wayland 
EGL_EXT_platform_wayland 
EGL_KHR_platform_gbm 
EGL_MESA_platform_gbm 
EGL_MESA_platform_xcb 

That final extension on the list does not appear on the registry and I couldn't find documentation for it anywhere.

Here's the output of eglinfo if it's at all relevant

EGL client extensions string:
    EGL_EXT_platform_base EGL_EXT_device_base EGL_EXT_device_enumeration
    EGL_EXT_device_query EGL_KHR_client_get_all_proc_addresses
    EGL_EXT_client_extensions EGL_KHR_debug EGL_KHR_platform_x11
    EGL_EXT_platform_x11 EGL_EXT_platform_device EGL_KHR_platform_wayland
    EGL_EXT_platform_wayland EGL_KHR_platform_gbm EGL_MESA_platform_gbm
    EGL_MESA_platform_xcb EGL_MESA_platform_surfaceless

GBM platform:
eglinfo: eglInitialize failed

Wayland platform:
EGL API version: 1.5
EGL vendor string: Mesa Project
EGL version string: 1.5
EGL client APIs: OpenGL OpenGL_ES 
EGL extensions string:
    EGL_ANDROID_blob_cache EGL_ANDROID_native_fence_sync
    EGL_EXT_buffer_age EGL_EXT_create_context_robustness
    EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers
    EGL_EXT_present_opaque EGL_EXT_swap_buffers_with_damage
    EGL_IMG_context_priority EGL_KHR_cl_event2 EGL_KHR_config_attribs
    EGL_KHR_create_context EGL_KHR_create_context_no_error
    EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses
    EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image
    EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image
    EGL_KHR_gl_texture_cubemap_image EGL_KHR_image_base
    EGL_KHR_no_config_context EGL_KHR_reusable_sync
    EGL_KHR_surfaceless_context EGL_KHR_swap_buffers_with_damage
    EGL_EXT_pixel_format_float EGL_KHR_wait_sync
    EGL_MESA_configless_context EGL_MESA_drm_image
    EGL_MESA_image_dma_buf_export EGL_MESA_query_driver
    EGL_WL_bind_wayland_display EGL_WL_create_wayland_buffer_from_image
Configurations:
     bf lv colorbuffer dp st  ms    vis   cav bi  renderable  supported
  id sz  l  r  g  b  a th cl ns b    id   eat nd gl es es2 vg surfaces 
---------------------------------------------------------------------
0x01 32  0 10 10 10  2  0  0  0 0 0x00--         y  y  y     win
0x02 32  0 10 10 10  2 16  0  0 0 0x00--         y  y  y     win
0x03 32  0 10 10 10  2 24  0  0 0 0x00--         y  y  y     win
0x04 32  0 10 10 10  2 24  8  0 0 0x00--         y  y  y     win
0x05 32  0 10 10 10  2  0  0  2 1 0x00--         y  y  y     win
0x06 32  0 10 10 10  2  0  0  4 1 0x00--         y  y  y     win
0x07 32  0 10 10 10  2  0  0  8 1 0x00--         y  y  y     win
0x08 32  0 10 10 10  2  0  0 16 1 0x00--         y  y  y     win
0x09 32  0 10 10 10  2 16  0  2 1 0x00--         y  y  y     win
0x0a 32  0 10 10 10  2 16  0  4 1 0x00--         y  y  y     win
0x0b 32  0 10 10 10  2 16  0  8 1 0x00--         y  y  y     win
0x0c 32  0 10 10 10  2 16  0 16 1 0x00--         y  y  y     win
0x0d 32  0 10 10 10  2 24  0  2 1 0x00--         y  y  y     win
0x0e 32  0 10 10 10  2 24  0  4 1 0x00--         y  y  y     win
0x0f 32  0 10 10 10  2 24  0  8 1 0x00--         y  y  y     win
0x10 32  0 10 10 10  2 24  0 16 1 0x00--         y  y  y     win
0x11 32  0 10 10 10  2 24  8  2 1 0x00--         y  y  y     win
0x12 32  0 10 10 10  2 24  8  4 1 0x00--         y  y  y     win
0x13 32  0 10 10 10  2 24  8  8 1 0x00--         y  y  y     win
0x14 32  0 10 10 10  2 24  8 16 1 0x00--         y  y  y     win
0x15 30  0 10 10 10  0  0  0  0 0 0x00--         y  y  y     win
0x16 30  0 10 10 10  0 16  0  0 0 0x00--         y  y  y     win
0x17 30  0 10 10 10  0 24  0  0 0 0x00--         y  y  y     win
0x18 30  0 10 10 10  0 24  8  0 0 0x00--         y  y  y     win
0x19 30  0 10 10 10  0  0  0  2 1 0x00--         y  y  y     win
0x1a 30  0 10 10 10  0  0  0  4 1 0x00--         y  y  y     win
0x1b 30  0 10 10 10  0  0  0  8 1 0x00--         y  y  y     win
0x1c 30  0 10 10 10  0  0  0 16 1 0x00--         y  y  y     win
0x1d 30  0 10 10 10  0 16  0  2 1 0x00--         y  y  y     win
0x1e 30  0 10 10 10  0 16  0  4 1 0x00--         y  y  y     win
0x1f 30  0 10 10 10  0 16  0  8 1 0x00--         y  y  y     win
0x20 30  0 10 10 10  0 16  0 16 1 0x00--         y  y  y     win
0x21 30  0 10 10 10  0 24  0  2 1 0x00--         y  y  y     win
0x22 30  0 10 10 10  0 24  0  4 1 0x00--         y  y  y     win
0x23 30  0 10 10 10  0 24  0  8 1 0x00--         y  y  y     win
0x24 30  0 10 10 10  0 24  0 16 1 0x00--         y  y  y     win
0x25 30  0 10 10 10  0 24  8  2 1 0x00--         y  y  y     win
0x26 30  0 10 10 10  0 24  8  4 1 0x00--         y  y  y     win
0x27 30  0 10 10 10  0 24  8  8 1 0x00--         y  y  y     win
0x28 30  0 10 10 10  0 24  8 16 1 0x00--         y  y  y     win
0x29 32  0  8  8  8  8  0  0  0 0 0x00--         y  y  y     win
0x2a 32  0  8  8  8  8 16  0  0 0 0x00--         y  y  y     win
0x2b 32  0  8  8  8  8 24  0  0 0 0x00--         y  y  y     win
0x2c 32  0  8  8  8  8 24  8  0 0 0x00--         y  y  y     win
0x2d 32  0  8  8  8  8  0  0  2 1 0x00--         y  y  y     win
0x2e 32  0  8  8  8  8  0  0  4 1 0x00--         y  y  y     win
0x2f 32  0  8  8  8  8  0  0  8 1 0x00--         y  y  y     win
0x30 32  0  8  8  8  8  0  0 16 1 0x00--         y  y  y     win
0x31 32  0  8  8  8  8 16  0  2 1 0x00--         y  y  y     win
0x32 32  0  8  8  8  8 16  0  4 1 0x00--         y  y  y     win
0x33 32  0  8  8  8  8 16  0  8 1 0x00--         y  y  y     win
0x34 32  0  8  8  8  8 16  0 16 1 0x00--         y  y  y     win
0x35 32  0  8  8  8  8 24  0  2 1 0x00--         y  y  y     win
0x36 32  0  8  8  8  8 24  0  4 1 0x00--         y  y  y     win
0x37 32  0  8  8  8  8 24  0  8 1 0x00--         y  y  y     win
0x38 32  0  8  8  8  8 24  0 16 1 0x00--         y  y  y     win
0x39 32  0  8  8  8  8 24  8  2 1 0x00--         y  y  y     win
0x3a 32  0  8  8  8  8 24  8  4 1 0x00--         y  y  y     win
0x3b 32  0  8  8  8  8 24  8  8 1 0x00--         y  y  y     win
0x3c 32  0  8  8  8  8 24  8 16 1 0x00--         y  y  y     win
0x3d 24  0  8  8  8  0  0  0  0 0 0x00--         y  y  y     win
0x3e 24  0  8  8  8  0 16  0  0 0 0x00--         y  y  y     win
0x3f 24  0  8  8  8  0 24  0  0 0 0x00--         y  y  y     win
0x40 24  0  8  8  8  0 24  8  0 0 0x00--         y  y  y     win
0x41 24  0  8  8  8  0  0  0  2 1 0x00--         y  y  y     win
0x42 24  0  8  8  8  0  0  0  4 1 0x00--         y  y  y     win
0x43 24  0  8  8  8  0  0  0  8 1 0x00--         y  y  y     win
0x44 24  0  8  8  8  0  0  0 16 1 0x00--         y  y  y     win
0x45 24  0  8  8  8  0 16  0  2 1 0x00--         y  y  y     win
0x46 24  0  8  8  8  0 16  0  4 1 0x00--         y  y  y     win
0x47 24  0  8  8  8  0 16  0  8 1 0x00--         y  y  y     win
0x48 24  0  8  8  8  0 16  0 16 1 0x00--         y  y  y     win
0x49 24  0  8  8  8  0 24  0  2 1 0x00--         y  y  y     win
0x4a 24  0  8  8  8  0 24  0  4 1 0x00--         y  y  y     win
0x4b 24  0  8  8  8  0 24  0  8 1 0x00--         y  y  y     win
0x4c 24  0  8  8  8  0 24  0 16 1 0x00--         y  y  y     win
0x4d 24  0  8  8  8  0 24  8  2 1 0x00--         y  y  y     win
0x4e 24  0  8  8  8  0 24  8  4 1 0x00--         y  y  y     win
0x4f 24  0  8  8  8  0 24  8  8 1 0x00--         y  y  y     win
0x50 24  0  8  8  8  0 24  8 16 1 0x00--         y  y  y     win
0x51 16  0  5  6  5  0  0  0  0 0 0x00--         y  y  y     win
0x52 16  0  5  6  5  0 16  0  0 0 0x00--         y  y  y     win
0x53 16  0  5  6  5  0 24  0  0 0 0x00--         y  y  y     win
0x54 16  0  5  6  5  0 24  8  0 0 0x00--         y  y  y     win
0x55 16  0  5  6  5  0  0  0  2 1 0x00--         y  y  y     win
0x56 16  0  5  6  5  0  0  0  4 1 0x00--         y  y  y     win
0x57 16  0  5  6  5  0  0  0  8 1 0x00--         y  y  y     win
0x58 16  0  5  6  5  0  0  0 16 1 0x00--         y  y  y     win
0x59 16  0  5  6  5  0 16  0  2 1 0x00--         y  y  y     win
0x5a 16  0  5  6  5  0 16  0  4 1 0x00--         y  y  y     win
0x5b 16  0  5  6  5  0 16  0  8 1 0x00--         y  y  y     win
0x5c 16  0  5  6  5  0 16  0 16 1 0x00--         y  y  y     win
0x5d 16  0  5  6  5  0 24  0  2 1 0x00--         y  y  y     win
0x5e 16  0  5  6  5  0 24  0  4 1 0x00--         y  y  y     win
0x5f 16  0  5  6  5  0 24  0  8 1 0x00--         y  y  y     win
0x60 16  0  5  6  5  0 24  0 16 1 0x00--         y  y  y     win
0x61 16  0  5  6  5  0 24  8  2 1 0x00--         y  y  y     win
0x62 16  0  5  6  5  0 24  8  4 1 0x00--         y  y  y     win
0x63 16  0  5  6  5  0 24  8  8 1 0x00--         y  y  y     win
0x64 16  0  5  6  5  0 24  8 16 1 0x00--         y  y  y     win
0x65 64  0 16 16 16 16  0  0  0 0 0x00--         y  y  y     win
0x66 64  0 16 16 16 16 16  0  0 0 0x00--         y  y  y     win
0x67 64  0 16 16 16 16 24  0  0 0 0x00--         y  y  y     win
0x68 64  0 16 16 16 16 24  8  0 0 0x00--         y  y  y     win
0x69 64  0 16 16 16 16  0  0  2 1 0x00--         y  y  y     win
0x6a 64  0 16 16 16 16  0  0  4 1 0x00--         y  y  y     win
0x6b 64  0 16 16 16 16  0  0  8 1 0x00--         y  y  y     win
0x6c 64  0 16 16 16 16  0  0 16 1 0x00--         y  y  y     win
0x6d 64  0 16 16 16 16 16  0  2 1 0x00--         y  y  y     win
0x6e 64  0 16 16 16 16 16  0  4 1 0x00--         y  y  y     win
0x6f 64  0 16 16 16 16 16  0  8 1 0x00--         y  y  y     win
0x70 64  0 16 16 16 16 16  0 16 1 0x00--         y  y  y     win
0x71 64  0 16 16 16 16 24  0  2 1 0x00--         y  y  y     win
0x72 64  0 16 16 16 16 24  0  4 1 0x00--         y  y  y     win
0x73 64  0 16 16 16 16 24  0  8 1 0x00--         y  y  y     win
0x74 64  0 16 16 16 16 24  0 16 1 0x00--         y  y  y     win
0x75 64  0 16 16 16 16 24  8  2 1 0x00--         y  y  y     win
0x76 64  0 16 16 16 16 24  8  4 1 0x00--         y  y  y     win
0x77 64  0 16 16 16 16 24  8  8 1 0x00--         y  y  y     win
0x78 64  0 16 16 16 16 24  8 16 1 0x00--         y  y  y     win
0x79 48  0 16 16 16  0  0  0  0 0 0x00--         y  y  y     win
0x7a 48  0 16 16 16  0 16  0  0 0 0x00--         y  y  y     win
0x7b 48  0 16 16 16  0 24  0  0 0 0x00--         y  y  y     win
0x7c 48  0 16 16 16  0 24  8  0 0 0x00--         y  y  y     win
0x7d 48  0 16 16 16  0  0  0  2 1 0x00--         y  y  y     win
0x7e 48  0 16 16 16  0  0  0  4 1 0x00--         y  y  y     win
0x7f 48  0 16 16 16  0  0  0  8 1 0x00--         y  y  y     win
0x80 48  0 16 16 16  0  0  0 16 1 0x00--         y  y  y     win
0x81 48  0 16 16 16  0 16  0  2 1 0x00--         y  y  y     win
0x82 48  0 16 16 16  0 16  0  4 1 0x00--         y  y  y     win
0x83 48  0 16 16 16  0 16  0  8 1 0x00--         y  y  y     win
0x84 48  0 16 16 16  0 16  0 16 1 0x00--         y  y  y     win
0x85 48  0 16 16 16  0 24  0  2 1 0x00--         y  y  y     win
0x86 48  0 16 16 16  0 24  0  4 1 0x00--         y  y  y     win
0x87 48  0 16 16 16  0 24  0  8 1 0x00--         y  y  y     win
0x88 48  0 16 16 16  0 24  0 16 1 0x00--         y  y  y     win
0x89 48  0 16 16 16  0 24  8  2 1 0x00--         y  y  y     win
0x8a 48  0 16 16 16  0 24  8  4 1 0x00--         y  y  y     win
0x8b 48  0 16 16 16  0 24  8  8 1 0x00--         y  y  y     win
0x8c 48  0 16 16 16  0 24  8 16 1 0x00--         y  y  y     win

X11 platform:
EGL API version: 1.5
EGL vendor string: Mesa Project
EGL version string: 1.5
EGL client APIs: OpenGL OpenGL_ES 
EGL extensions string:
    EGL_ANDROID_blob_cache EGL_ANDROID_native_fence_sync
    EGL_CHROMIUM_sync_control EGL_EXT_buffer_age
    EGL_EXT_create_context_robustness EGL_EXT_image_dma_buf_import
    EGL_EXT_image_dma_buf_import_modifiers
    EGL_EXT_swap_buffers_with_damage EGL_IMG_context_priority
    EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_create_context
    EGL_KHR_create_context_no_error EGL_KHR_fence_sync
    EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace
    EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image
    EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image
    EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap
    EGL_KHR_no_config_context EGL_KHR_reusable_sync
    EGL_KHR_surfaceless_context EGL_KHR_swap_buffers_with_damage
    EGL_EXT_pixel_format_float EGL_KHR_wait_sync
    EGL_MESA_configless_context EGL_MESA_drm_image
    EGL_MESA_image_dma_buf_export EGL_MESA_query_driver
    EGL_NOK_texture_from_pixmap EGL_WL_bind_wayland_display
Configurations:
     bf lv colorbuffer dp st  ms    vis   cav bi  renderable  supported
  id sz  l  r  g  b  a th cl ns b    id   eat nd gl es es2 vg surfaces 
---------------------------------------------------------------------
0x01 32  0  8  8  8  8  0  0  0 0 0x3bTC      a  y  y  y     win,pb,pix
0x02 32  0  8  8  8  8 16  0  0 0 0x3bTC      a  y  y  y     win,pb,pix
0x03 32  0  8  8  8  8 24  0  0 0 0x3bTC      a  y  y  y     win,pb,pix
0x04 32  0  8  8  8  8 24  8  0 0 0x3bTC      a  y  y  y     win,pb,pix
0x05 32  0  8  8  8  8  0  0  2 1 0x3bTC      a  y  y  y     win,pb,pix
0x06 32  0  8  8  8  8  0  0  4 1 0x3bTC      a  y  y  y     win,pb,pix
0x07 32  0  8  8  8  8  0  0  8 1 0x3bTC      a  y  y  y     win,pb,pix
0x08 32  0  8  8  8  8  0  0 16 1 0x3bTC      a  y  y  y     win,pb,pix
0x09 32  0  8  8  8  8 16  0  2 1 0x3bTC      a  y  y  y     win,pb,pix
0x0a 32  0  8  8  8  8 16  0  4 1 0x3bTC      a  y  y  y     win,pb,pix
0x0b 32  0  8  8  8  8 16  0  8 1 0x3bTC      a  y  y  y     win,pb,pix
0x0c 32  0  8  8  8  8 16  0 16 1 0x3bTC      a  y  y  y     win,pb,pix
0x0d 32  0  8  8  8  8 24  0  2 1 0x3bTC      a  y  y  y     win,pb,pix
0x0e 32  0  8  8  8  8 24  0  4 1 0x3bTC      a  y  y  y     win,pb,pix
0x0f 32  0  8  8  8  8 24  0  8 1 0x3bTC      a  y  y  y     win,pb,pix
0x10 32  0  8  8  8  8 24  0 16 1 0x3bTC      a  y  y  y     win,pb,pix
0x11 32  0  8  8  8  8 24  8  2 1 0x3bTC      a  y  y  y     win,pb,pix
0x12 32  0  8  8  8  8 24  8  4 1 0x3bTC      a  y  y  y     win,pb,pix
0x13 32  0  8  8  8  8 24  8  8 1 0x3bTC      a  y  y  y     win,pb,pix
0x14 32  0  8  8  8  8 24  8 16 1 0x3bTC      a  y  y  y     win,pb,pix
0x15 24  0  8  8  8  0  0  0  0 0 0x3bTC      y  y  y  y     win,pb,pix
0x16 24  0  8  8  8  0 16  0  0 0 0x3bTC      y  y  y  y     win,pb,pix
0x17 24  0  8  8  8  0 24  0  0 0 0x3bTC      y  y  y  y     win,pb,pix
0x18 24  0  8  8  8  0 24  8  0 0 0x3bTC      y  y  y  y     win,pb,pix
0x19 24  0  8  8  8  0  0  0  2 1 0x3bTC      y  y  y  y     win,pb,pix
0x1a 24  0  8  8  8  0  0  0  4 1 0x3bTC      y  y  y  y     win,pb,pix
0x1b 24  0  8  8  8  0  0  0  8 1 0x3bTC      y  y  y  y     win,pb,pix
0x1c 24  0  8  8  8  0  0  0 16 1 0x3bTC      y  y  y  y     win,pb,pix
0x1d 24  0  8  8  8  0 16  0  2 1 0x3bTC      y  y  y  y     win,pb,pix
0x1e 24  0  8  8  8  0 16  0  4 1 0x3bTC      y  y  y  y     win,pb,pix
0x1f 24  0  8  8  8  0 16  0  8 1 0x3bTC      y  y  y  y     win,pb,pix
0x20 24  0  8  8  8  0 16  0 16 1 0x3bTC      y  y  y  y     win,pb,pix
0x21 24  0  8  8  8  0 24  0  2 1 0x3bTC      y  y  y  y     win,pb,pix
0x22 24  0  8  8  8  0 24  0  4 1 0x3bTC      y  y  y  y     win,pb,pix
0x23 24  0  8  8  8  0 24  0  8 1 0x3bTC      y  y  y  y     win,pb,pix
0x24 24  0  8  8  8  0 24  0 16 1 0x3bTC      y  y  y  y     win,pb,pix
0x25 24  0  8  8  8  0 24  8  2 1 0x3bTC      y  y  y  y     win,pb,pix
0x26 24  0  8  8  8  0 24  8  4 1 0x3bTC      y  y  y  y     win,pb,pix
0x27 24  0  8  8  8  0 24  8  8 1 0x3bTC      y  y  y  y     win,pb,pix
0x28 24  0  8  8  8  0 24  8 16 1 0x3bTC      y  y  y  y     win,pb,pix
0x29 32  0  8  8  8  8  0  0  0 0 0x3cDC      a  y  y  y     win,pb,pix
0x2a 32  0  8  8  8  8 16  0  0 0 0x3cDC      a  y  y  y     win,pb,pix
0x2b 32  0  8  8  8  8 24  0  0 0 0x3cDC      a  y  y  y     win,pb,pix
0x2c 32  0  8  8  8  8 24  8  0 0 0x3cDC      a  y  y  y     win,pb,pix
0x2d 32  0  8  8  8  8  0  0  2 1 0x3cDC      a  y  y  y     win,pb,pix
0x2e 32  0  8  8  8  8  0  0  4 1 0x3cDC      a  y  y  y     win,pb,pix
0x2f 32  0  8  8  8  8  0  0  8 1 0x3cDC      a  y  y  y     win,pb,pix
0x30 32  0  8  8  8  8  0  0 16 1 0x3cDC      a  y  y  y     win,pb,pix
0x31 32  0  8  8  8  8 16  0  2 1 0x3cDC      a  y  y  y     win,pb,pix
0x32 32  0  8  8  8  8 16  0  4 1 0x3cDC      a  y  y  y     win,pb,pix
0x33 32  0  8  8  8  8 16  0  8 1 0x3cDC      a  y  y  y     win,pb,pix
0x34 32  0  8  8  8  8 16  0 16 1 0x3cDC      a  y  y  y     win,pb,pix
0x35 32  0  8  8  8  8 24  0  2 1 0x3cDC      a  y  y  y     win,pb,pix
0x36 32  0  8  8  8  8 24  0  4 1 0x3cDC      a  y  y  y     win,pb,pix
0x37 32  0  8  8  8  8 24  0  8 1 0x3cDC      a  y  y  y     win,pb,pix
0x38 32  0  8  8  8  8 24  0 16 1 0x3cDC      a  y  y  y     win,pb,pix
0x39 32  0  8  8  8  8 24  8  2 1 0x3cDC      a  y  y  y     win,pb,pix
0x3a 32  0  8  8  8  8 24  8  4 1 0x3cDC      a  y  y  y     win,pb,pix
0x3b 32  0  8  8  8  8 24  8  8 1 0x3cDC      a  y  y  y     win,pb,pix
0x3c 32  0  8  8  8  8 24  8 16 1 0x3cDC      a  y  y  y     win,pb,pix
0x3d 24  0  8  8  8  0  0  0  0 0 0x3cDC      y  y  y  y     win,pb,pix
0x3e 24  0  8  8  8  0 16  0  0 0 0x3cDC      y  y  y  y     win,pb,pix
0x3f 24  0  8  8  8  0 24  0  0 0 0x3cDC      y  y  y  y     win,pb,pix
0x40 24  0  8  8  8  0 24  8  0 0 0x3cDC      y  y  y  y     win,pb,pix
0x41 24  0  8  8  8  0  0  0  2 1 0x3cDC      y  y  y  y     win,pb,pix
0x42 24  0  8  8  8  0  0  0  4 1 0x3cDC      y  y  y  y     win,pb,pix
0x43 24  0  8  8  8  0  0  0  8 1 0x3cDC      y  y  y  y     win,pb,pix
0x44 24  0  8  8  8  0  0  0 16 1 0x3cDC      y  y  y  y     win,pb,pix
0x45 24  0  8  8  8  0 16  0  2 1 0x3cDC      y  y  y  y     win,pb,pix
0x46 24  0  8  8  8  0 16  0  4 1 0x3cDC      y  y  y  y     win,pb,pix
0x47 24  0  8  8  8  0 16  0  8 1 0x3cDC      y  y  y  y     win,pb,pix
0x48 24  0  8  8  8  0 16  0 16 1 0x3cDC      y  y  y  y     win,pb,pix
0x49 24  0  8  8  8  0 24  0  2 1 0x3cDC      y  y  y  y     win,pb,pix
0x4a 24  0  8  8  8  0 24  0  4 1 0x3cDC      y  y  y  y     win,pb,pix
0x4b 24  0  8  8  8  0 24  0  8 1 0x3cDC      y  y  y  y     win,pb,pix
0x4c 24  0  8  8  8  0 24  0 16 1 0x3cDC      y  y  y  y     win,pb,pix
0x4d 24  0  8  8  8  0 24  8  2 1 0x3cDC      y  y  y  y     win,pb,pix
0x4e 24  0  8  8  8  0 24  8  4 1 0x3cDC      y  y  y  y     win,pb,pix
0x4f 24  0  8  8  8  0 24  8  8 1 0x3cDC      y  y  y  y     win,pb,pix
0x50 24  0  8  8  8  0 24  8 16 1 0x3cDC      y  y  y  y     win,pb,pix

Device platform:
EGL API version: 1.5
EGL vendor string: NVIDIA
EGL version string: 1.5
EGL client APIs: OpenGL_ES OpenGL
EGL extensions string:
    EGL_EXT_buffer_age EGL_EXT_client_sync
    EGL_EXT_create_context_robustness EGL_EXT_image_dma_buf_import
    EGL_EXT_image_dma_buf_import_modifiers EGL_MESA_image_dma_buf_export
    EGL_EXT_output_base EGL_EXT_output_drm EGL_EXT_protected_content
    EGL_EXT_stream_consumer_egloutput EGL_EXT_stream_acquire_mode
    EGL_EXT_sync_reuse EGL_IMG_context_priority EGL_KHR_config_attribs
    EGL_KHR_create_context_no_error EGL_KHR_context_flush_control
    EGL_KHR_create_context EGL_KHR_fence_sync
    EGL_KHR_get_all_proc_addresses EGL_KHR_partial_update
    EGL_KHR_swap_buffers_with_damage EGL_KHR_no_config_context
    EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image
    EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image
    EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base
    EGL_KHR_reusable_sync EGL_KHR_stream EGL_KHR_stream_attrib
    EGL_KHR_stream_consumer_gltexture EGL_KHR_stream_cross_process_fd
    EGL_KHR_stream_fifo EGL_KHR_stream_producer_eglsurface
    EGL_KHR_surfaceless_context EGL_KHR_wait_sync EGL_NV_nvrm_fence_sync
    EGL_NV_quadruple_buffer EGL_NV_stream_consumer_eglimage
    EGL_NV_stream_cross_display EGL_NV_stream_cross_object
    EGL_NV_stream_cross_process EGL_NV_stream_cross_system
    EGL_NV_stream_dma EGL_NV_stream_flush EGL_NV_stream_metadata
    EGL_NV_stream_remote EGL_NV_stream_reset EGL_NV_stream_socket
    EGL_NV_stream_socket_inet EGL_NV_stream_socket_unix
    EGL_NV_stream_sync EGL_NV_stream_fifo_next
    EGL_NV_stream_fifo_synchronous EGL_NV_stream_consumer_gltexture_yuv
    EGL_NV_stream_attrib EGL_NV_stream_origin EGL_NV_system_time
    EGL_NV_output_drm_flip_event EGL_NV_triple_buffer
    EGL_NV_robustness_video_memory_purge EGL_WL_bind_wayland_display
    EGL_WL_wayland_eglstream
Configurations:
     bf lv colorbuffer dp st  ms    vis   cav bi  renderable  supported
  id sz  l  r  g  b  a th cl ns b    id   eat nd gl es es2 vg surfaces 
---------------------------------------------------------------------
0x01 32  0  8  8  8  8 24  8  0 0 0x00--         y  y  y     pb,str
0x02 32  0  8  8  8  8 24  0  0 0 0x00--         y  y  y     pb,str
0x03 32  0  8  8  8  8  0  0  0 0 0x00--         y  y  y     pb,str
0x04 32  0  8  8  8  8 24  8  2 1 0x00--         y  y  y     pb,str
0x05 32  0  8  8  8  8 24  0  2 1 0x00--         y  y  y     pb,str
0x06 32  0  8  8  8  8  0  0  2 1 0x00--         y  y  y     pb,str
0x07 32  0  8  8  8  8 24  8  4 1 0x00--         y  y  y     pb,str
0x08 32  0  8  8  8  8 24  8  4 1 0x00--         y  y  y     pb,str
0x09 32  0  8  8  8  8 24  0  4 1 0x00--         y  y  y     pb,str
0x0a 32  0  8  8  8  8 24  0  4 1 0x00--         y  y  y     pb,str
0x0b 32  0  8  8  8  8  0  0  4 1 0x00--         y  y  y     pb,str
0x0c 32  0  8  8  8  8  0  0  4 1 0x00--         y  y  y     pb,str
0x0d 32  0  8  8  8  8 24  8  8 1 0x00--         y  y  y     pb,str
0x0e 32  0  8  8  8  8 24  0  8 1 0x00--         y  y  y     pb,str
0x0f 32  0  8  8  8  8  0  0  8 1 0x00--         y  y  y     pb,str
0x10 24  0  8  8  8  0 24  8  0 0 0x00--         y  y  y     pb,str
0x11 24  0  8  8  8  0 24  0  0 0 0x00--         y  y  y     pb,str
0x12 24  0  8  8  8  0  0  0  0 0 0x00--         y  y  y     pb,str
0x13 24  0  8  8  8  0 24  8  2 1 0x00--         y  y  y     pb,str
0x14 24  0  8  8  8  0 24  0  2 1 0x00--         y  y  y     pb,str
0x15 24  0  8  8  8  0  0  0  2 1 0x00--         y  y  y     pb,str
0x16 24  0  8  8  8  0 24  8  4 1 0x00--         y  y  y     pb,str
0x17 24  0  8  8  8  0 24  8  4 1 0x00--         y  y  y     pb,str
0x18 24  0  8  8  8  0 24  0  4 1 0x00--         y  y  y     pb,str
0x19 24  0  8  8  8  0 24  0  4 1 0x00--         y  y  y     pb,str
0x1a 24  0  8  8  8  0  0  0  4 1 0x00--         y  y  y     pb,str
0x1b 24  0  8  8  8  0  0  0  4 1 0x00--         y  y  y     pb,str
0x1c 24  0  8  8  8  0 24  8  8 1 0x00--         y  y  y     pb,str
0x1d 24  0  8  8  8  0 24  0  8 1 0x00--         y  y  y     pb,str
0x1e 24  0  8  8  8  0  0  0  8 1 0x00--         y  y  y     pb,str
0x1f 16  0  5  6  5  0 24  8  0 0 0x00--         y  y  y     pb,str
0x20 16  0  5  6  5  0 24  0  0 0 0x00--         y  y  y     pb,str
0x21 16  0  5  6  5  0 16  0  0 0 0x00--         y  y  y     pb,str
0x22 16  0  5  6  5  0  0  0  0 0 0x00--         y  y  y     pb,str
0x23 16  0  5  6  5  0 24  8  2 1 0x00--         y  y  y     pb,str
0x24 16  0  5  6  5  0 24  0  2 1 0x00--         y  y  y     pb,str
0x25 16  0  5  6  5  0 16  0  2 1 0x00--         y  y  y     pb,str
0x26 16  0  5  6  5  0  0  0  2 1 0x00--         y  y  y     pb,str
0x27 16  0  5  6  5  0 24  8  4 1 0x00--         y  y  y     pb,str
0x28 16  0  5  6  5  0 24  8  4 1 0x00--         y  y  y     pb,str
0x29 16  0  5  6  5  0 24  0  4 1 0x00--         y  y  y     pb,str
0x2a 16  0  5  6  5  0 24  0  4 1 0x00--         y  y  y     pb,str
0x2b 16  0  5  6  5  0 16  0  4 1 0x00--         y  y  y     pb,str
0x2c 16  0  5  6  5  0 16  0  4 1 0x00--         y  y  y     pb,str
0x2d 16  0  5  6  5  0  0  0  4 1 0x00--         y  y  y     pb,str
0x2e 16  0  5  6  5  0  0  0  4 1 0x00--         y  y  y     pb,str
0x2f 16  0  5  6  5  0 24  8  8 1 0x00--         y  y  y     pb,str
0x30 16  0  5  6  5  0 24  0  8 1 0x00--         y  y  y     pb,str
0x31 16  0  5  6  5  0 16  0  8 1 0x00--         y  y  y     pb,str
0x32 16  0  5  6  5  0  0  0  8 1 0x00--         y  y  y     pb,str

Simple code cleanup to alphabetize these typedefs.

I am new to EGL and I have to use libEgl.lib on one of my projects. We are using QT Creator as the IDE.
When running the application it returns "num_config" as zero in eglChooseConfig function. But the same code runs without any issue in visual studio. Could somebody guide me on this whether there is any dependency for the EGL library.

There are cases where an application may want to apply the sRGB transfer function as part of it's shader computations and would like to use the non-linear Display-P3 color space. However, the current EGL_EXT_gl_colorspace_display_p3 will always use the HW sRGB support for 8-bit pixel formats.

The eglGetCurrentSurface() manpage doesn't list the two valid enum values for the readdraw parameter, EGL_READ and EGL_DRAW.

See the EGL 1.5 Specification, section 3.7.4 "Context Queries", page 62.

https://registry.khronos.org/EGL/sdk/docs/man/html/eglCreateContext.xhtml attrib_list parameter explanation says

Only the attribute EGL_CONTEXT_CLIENT_VERSION may be specified.

Word may looks like a typo, since in eglCreateContext function description a lot more attributes are mentioned which may be specified.

@stonesthrow and other interested parties: heads-up that we propose to rename the default branch of this repository to 'main' in late August 2021, following emerging Khronos & github practice (for Khronos members, see internal khronos-general issue 106). This will have very little impact, although if you have a checked-out repository clone, you may want to follow the simple instructions github will pop up on the repository webpage describing how to do the same locally.

If there is a concern about this, please raise it here by 2021-08-23.

Hi, I have tried to run a 3D Similator in the repo on a nvidia-docker container. However, when I ran the unittest which did some rendering jobs, an unusual error was encountered:

/root/mount/Matterport3DSimulator/src/test/main.cpp:350: FAILED:
REQUIRE_NOTHROW( sim.initialize() )
due to unexpected exception with message:
EGL error 0x300c at eglGetDisplay

test cases: 5 | 4 passed | 1 failed
assertions: 119187 | 119186 passed | 1 failed

According to the test code, I think it is just related to the following code in MatterSim.cpp: line169~177:

       // Initialize EGL
        eglDpy = eglGetDisplay(EGL_DEFAULT_DISPLAY);
        assertEGLError("eglGetDisplay");

        EGLint major, minor;

        eglInitialize(eglDpy, &major, &minor);
        assertEGLError("eglInitialize");

I feel strange that eglGetDisplay rerturns 0x300c and have no idea to solve this problem.
How can I fix it? Do I need to bind some physical display devices to the container or set the environment DISPLAY in the container to let the system access display devices?

Thx!m

While implementing EGL_EXT_device_drm in Mesa I've noticed that the token is missing.
I did not look closely exactly what need to be tweaked, hence this issue instead of a PR.

Might be worth checking the other EGL Device/Output extensions for missing parts.

@dkartch-nv @cubanismo @1ace

I have a use case where I need to create an image from a dmabuf using
eglCreateImageKHR, then import it as a GL_DEPTH_COMPONENT/GL_DEPTH_STENCIL
texture using glEGLImageTargetTexture2DOES. It seems that the second step
assumes that the texture format is always GL_RGBA, which forces me to use a shader
to blit the depth of my framebuffer onto the second image

Here's the simplified code of my process

EGLint color_attribs[] = {
	// DMAbuf config
	EGL_LINUX_DRM_FOURCC_EXT, DRM_FORMAT_ARGB8888,
}

EGLImageKHR color_image = eglCreateImageKHR(display, EGL_NO_CONTEXT, 
		EGL_LINUX_DMA_BUF_EXT, NULL, color_attribs);

EGLint depth_attribs[] = {
	// DMAbuf config
	EGL_LINUX_DRM_FOURCC_EXT, DRM_FORMAT_R16,
}

EGLImageKHR depth_image = eglCreateImageKHR(display, EGL_NO_CONTEXT, 
		EGL_LINUX_DMA_BUF_EXT, NULL, depth_attribs);
		

glBindTexture(GL_TEXTURE_2D, color_tex);
glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, color_image);

glBindTexture(GL_TEXTURE_2D, depth);
glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT16, width, height, 0,
 		GL_DEPTH_COMPONENT, GL_UNSIGNED_INT, NULL);

glBindTexture(GL_TEXTURE_2D, depth_tex);
glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, depth_image);

                                     
glBindFramebuffer(GL_FRAMEBUFFER, fbo);                             
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,                
		GL_TEXTURE_2D, color_tex, 0);                               
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT1,                
		GL_TEXTURE_2D, depth_tex, 0);                               
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT,                 
		GL_TEXTURE_2D, depth, 0);

This feels a bit heavy. Would there be a way to use the EGLImage as a depth
attachment directly? Maybe add a fourcc format to express depth/stencil and have
the driver translate the format into GL format, or add a parameter to one of the
function so let the user specify the desired GL format regardless of the dmabuf
format?

I'd be happy to help and contribute to a simpler solution.

Right now it's non-const.

Could the tools necessary to validate EGL registry changes, as requested in the README.md - for example, running "make validate" in the api/ directory - please be documented?

It would be great if instructions could be given for all of Linux, macOS and Windows.

Thanks.

I did install libegl1-mesa and libegl1-mesa-dev on my ubuntu platform. But when I run the sample code from nvdiffrast, there is a error and reports /usr/bin/ld: cannot find -lEGL. How can I fix this plz?

Hi KhronosGroup team,

we found that this EGL-Registry may have some mistake with EGL spec,
In this Registry, Regards to eglCreatePbufferSurface.xhtml,

Description
eglCreatePbufferSurface creates an off-screen pixel buffer surface and returns its handle. If eglCreatePbufferSurface fails to create a pixel buffer surface, EGL_NO_SURFACE is returned.

Surface attributes are specified as a list of attribute-value pairs, terminated with EGL_NONE. Accepted attributes are:

EGL_GL_COLORSPACE
Specifies the color space used by OpenGL and OpenGL ES when rendering to the surface. If its value is EGL_GL_COLORSPACE_SRGB, then a non-linear, perceptually uniform color space is assumed, with a corresponding GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING value of GL_SRGB. If its value is EGL_GL_COLORSPACE_LINEAR, then a linear color space is assumed, with a corresponding GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING value of GL_LINEAR. The default value of EGL_GL_COLORSPACE is EGL_GL_COLORSPACE_SRGB.

We can see the default value of EGL_GL_COLORSPACE is EGL_GL_COLORSPACE_SRGB.

But according to EGL-1.5 spec:
https://www.khronos.org/registry/EGL/specs/eglspec.1.5.pdf
Got info from eglCreatePlatformWindowSurface

Got info from eglCreatePbufferSurface

So, could you please help to check this gap and make an alignment for EGL-Registry with EGL spec ？ Many thanks.

Best Regards,
Junbo

The khronos_utime_nanoseconds_t type is declared in egl.xml on the following line:
<type name="khronos_utime_nanoseconds_t" requires="khrplatform"/>

However, khronos_stime_nanoseconds_t isn't. The following line needs to be added:
<type name="khronos_stime_nanoseconds_t" requires="khrplatform"/>

Currently this is breaking my code generation.

For example, PR #20 changed the contents of KHR/khrplatform.h, but the revision on line 29 hasn't changed, and still says:

$Revision: 32517 $ on $Date: 2016-03-11 02:41:19 -0800 (Fri, 11 Mar 2016) $

I haven't look into it much yet, but I think we should update genheaders.py (and the Makefile) to regenerate KHR/khrplatform.h as well.