The 2013.02.11 update to the EGL 1.4 spec made a subtle change to the behavior of the bound EGL API. The change was +EGL_OPENGL_API and EGL_OPENGL_ES_API are interchangeable for all pur- +poses except eglCreateContext [fn17]. See footnote 17 on page 43 (50 of pdf) for more info. Mesa's EGL needs the corresponding update, and Piglit tests are needed.
I noticed this while working on how to deal with the rendering API in libglvnd. I sent a patch out yesterday that combines the GL and GLES current context pointers into a single pointer. Almost everything else just falls out from that.
Fixed by: commit 6e066f76ee22909b0653ff8b89429de819e60f14 Author: Kyle Brenneman <kbrenneman@nvidia.com> AuthorDate: Fri Jul 8 15:21:17 2016 -0600 Commit: Adam Jackson <ajax@redhat.com> CommitDate: Wed Sep 7 11:56:48 2016 -0400 EGL: Combine the GL and GLES current contexts (v2) Only keep track of a single current context, instead of separate contexts for GL and GLES. In EGL 1.4 (and 1.5), EGL_OPENGL_API and EGL_OPENGL_ES_API are supposed to be interchangeable for all purposes except for eglCreateContext. The _EGLThreadInfo::CurrentContexts array is now a single pointer to the current context, which may be a GL or GLES context. In addition, it now keeps track of the current API as an enum instead of an index. eglMakeCurrent will now replace the current context, regardless of which client API is used for for the current and new contexts. It no longer checks for a conflicting context. In addition, calling eglMakeCurrent with EGL_NO_CONTEXT will now release the current context regardless of the current API. v2: Rebased against master (Adam Jackson) Reviewed-by: Adam Jackson <ajax@redhat.com>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.