Native surface creation
ajax at nwnk.net
Fri Mar 11 10:48:32 PST 2005
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:
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,
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,
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
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dri-egl/attachments/20050311/4adae7da/attachment.pgp
More information about the dri-egl