[Mesa-dev] Mesa EGL extensions

[nobled]

This is a little long, but I was wondering about a couple of the EGL
extensions Mesa implements:

Re: the new EGL_KHR_screenless_opengl and friends that took up the
functionality of EGL_MESA_no_surface - are there specs for those
anywhere on the web? Google gave nothing but Mesa itself, and the KHR
string says it's a Khronos extension, but I can't find it on the
Khronos EGL registry page[1]. Where'd they come from?

Are there any docs for EGL_NOK_texture_from_pixmap either? Mesa's the
only reference I can find for that, too.

Also, the EGL_MESA_screen_surface spec[2] still says it's preliminary
and totally subject to change -- if that's still true, shouldn't it
not be shipped by default if it doesn't guarantee
backwards-compatibility, maybe leave it out unless someone passes a
flag like -DEGL_MESA_screen_surface deliberately? (It also looks like
it hasn't been touched since before the EGL headers were added in Mesa
7.5; are there any changes planned?)

'Cause one reason it probably *shouldn't* offer
backwards-compatibility is it's using EGL enums that are intentionally
just outside the available range[3]. Could someone official file for
an allocation of vendor extension enums for Mesa with Khronos?
(instructions in [3])

Finally, a few things about the new EGL_MESA_drm_image extension:
- Is it also using unallocated enums? They're in the 0x31D0
"any_vendor_use" range in the eglenum.spec file, but I think that
means 'these might belong to any vendor after Khronos allocates them;
aka Reserved', based on the instructions after that seeming to be
directed to Khronos employees who can edit the file.
- The spec file should probably go in src/egl/docs/, not in docs/ with
the OpenGL extensions.
- Same concerns about backwards-compatibility as with the
screen_surface extension - should it require an explicit -D define
until it's finalized?
- The spec allows creating an EGLImageKHR from scratch, then exporting
the underlying DRM handle, then creating a new EGLImage from that
using the standard eglCreateImageKHR call. The exporting is what lets
clients integrate with the modesetting API, but the point of
'importing' a DRM handle is to make passing the EGLImage between
processes possible, right? The trouble is that seems to go against the
EGL_KHR_image_base spec for creating EGLImages from existing EGLImage
siblings/targets/sources:[4]

       * If the resource specified by <dpy>, <ctx>, <target>, <buffer> and
         <attrib_list> is itself an EGLImage sibling, the error
         EGL_BAD_ACCESS is generated.

It's discussed in more detail in Issues #4 and #5. I might be missing
something - can the requirement even apply to sources shared across
processes? - but if drm_image does need to contradict the base
EGLImage extension, that should probably be pointed out and more
explicitly justified (and if not, then it should clarify how it isn't
contradictory).

[1] http://www.khronos.org/registry/egl/
[2] http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/docs/EGL_MESA_screen_surface
[3] http://www.khronos.org/registry/egl/api/eglenum.spec
[4] http://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_image_base.txt