Native surface creation

[Adam Jackson]

First of all, hello all, thanks for subscribing.  For people who don't have 
copies of the spec handy, the EGL manual is available online at:

http://www.khronos.org/opengles/documentation/opengles1_1/gl_egl_ref_1_1_20041110/index.html

I've been thinking a bit about how to get surface creation handled properly.  
The application I'm targeting with this is Xgl, an X server running directly 
on a GL stack.  I would like to leverage the EGL API for this as much as 
possible.  The first problem, of course, is setting up the framebuffer for 
drawing.  It's important to not require X client headers for this, for two 
reasons.  One, Xegl conceptually isn't an X client.  Two, someone might want 
to write some other window system or native EGL app that doesn't rely on any 
other existing window system.

The existing API is:

EGLSurface eglCreateWindowSurface(EGLDisplay display,
                                  EGLconfig config,
                                  NativeWindowType native_window,
                                  EGLint const *attrib_list);

eglCreateWindowSurface expects the application to have already created a 
window.  Native EGL applications don't have any way to create a window 
because they are the window system and they haven't bootstrapped yet.  
eglCreatePixmapSurface has a similar problem.

We could create a new token for the native_window or attrib_list parameters 
that becomes a magic word for "create a new surface please" but I'm not sure 
I like that idea.  Overloading native_window in particular seems like a bad 
idea because NativeWindowType is opaque, and we could reasonably have 
collisions between the EGL enum space and (say) the XID space.  Adding 
attributes is relatively risk free since right now that parameter is unused 
for window creation.

Alternatively we could create a new entrypoint:

EGLSurface eglSetupFramebufferXXX(EGLDisplay display,
                                  EGLConfig config,
                                  EGLint const *attrib_list);

I don't know that this is different enough from CreateWindowSurface to justify 
another entrypoint, when we could just ignore the native_window arg.  It's 
reasonable in either approach to add several new valid attributes to the 
list: resolution, color depth, refresh rate, interlacing/doublescan, etc.

So much for the API.  On the implementation side, assume there's some bit in 
the EGLDisplay that specifies what device we're operating on (I'll talk more 
about this in another post), or else a handle to a low-level context or 
dispatch table, or whatever.  For "native" surface creation we can just hand 
this request down to the driver level for that EGLDisplay and the driver can 
implement it however it likes, it's a black box as far as the EGL engine is 
concerned.

All of this happens after we have a valid EGLDisplay, so we can check for this 
extension using eglQueryString.

Comments?  Has anyone seen this addressed in other GLES implementations?

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dri-egl/attachments/20050311/4adae7da/attachment.pgp