What is the status of EGL_MESA_screen_surface?

[Brian Paul]

Paul Ramsey wrote:
> I'm new to DRI EGL but I'm definitely not new to API design.
> 
> What is the status of EGL_MESA_screen_surface? Has this been discussed at
> Khronos as an extension to EGL?

It's kind of been in limbo for a while.  I've been focused on other 
projects for a while, but I've been tweaking the spec a little here 
and there.

It hasn't been circulated in Khronos yet, but probably should be.


> I've read through the entire archive of this list going back to last March and
> one fundamental thing I can't find is how EGL went from being an API for
> implementing OpenGL on a graphics device to being an API for being able to
> implement a window system on the device.

Don't think of it as just a basis for a window system, but as a 
cross-platform interface for "full-screen" OpenGL.

There's a lot of people out there who want to use OpenGL but don't 
want/need an X server.  For example, in embedded/vehicle applications. 
  In the past we devised a "mini GLX" API that used fbdev to use the 
DRI drivers outside of X.

The proposed EGL extension approach is much cleaner and has many 
possible applications.  Running an X server on top of it is just one 
example (an especially interesting one, but that's another topic).


> While I might disagree with some of the details, fundamentally all of the
> capabilities in EGL_MESA_screen_surface are important capabilities for building
> a window system, but I don't see why this is an EGL extension rather than part
> of a the native environment under which EGL runs. Being the native environment,
> EGL would have some knowledge of operations which happened in this screen/video
> mode control library but that doesn't require that it be in the form of an
> extension to EGL.

The idea is to provide a complete interface so the developer doesn't 
have to be concerned with any other lower-level native environment. 
The implementation of EGL_MESA_screen_surface (and EGL itself) might 
of course tie into a lower-level interface such as fbdev, or it might 
program the hardware directly.  In any case, the EGL application 
developer doesn't have to care.


> I would propose that
> 
> 1. These functions should be changed to not use the EGL or egl prefix
> 
> 2. eglCreateScreenSurface (or it's renamed equivalent) should return a handle
>    to a displayable frame buffer objects but that it isn't a "Surface". I'll
>    call it PREFIXDisplaybuffer for the moment.

We want to be able to call eglMakeCurrent() to bind a context to a 
screen surface so we can draw to it directly.


> 3. A native way needs to be created for referring to a device, this would get
>    passed into these functions rather than EGLDisplay. This would also
>    get passed into eglGetDisplay() to get a corresponding EGLDisplay. The
>    most trivial change to the existing implementation, PREFIXDevice would
>    really be the same as EGLDisplay, just typed different for the interface
>    definition.

We basically hijacked the EGLDisplay parameter to use it as a device 
handle.  Not especially elegant, but perfectly functional.

We should probably at least define an eglOpenDeviceMESA() function to 
get an EGLDisplay handle, rather than use eglGetDisplay().


> 4. eglCreateWindowSurface() would accept these PREFIXDisplaybuffer objects
>    to introduce them into EGL to make them into a window as an EGLSurface

I guess one could do that, but I think it's simpler to just have a new 
sub-type of drawing surface.  Also, we don't have to worry if all the 
EGL window surface properties/semantics apply to screen surfaces, and 
vice versa.


> Otherwise the functions could stay as they are. This isn't really a major change
> to the interface as it's defined, just getting it out of EGL where it doesn't
> belong.
> 
> If everyone wants to send the mail telling me why I'm an idiot directly to me,
> I'll summarize to the list. :-)

All reasonable questions.

-Brian