eglCreateWindowSurface fails with error 12299 on pandaboard

Bug #855524 reported by Marc Ordinas i Llopis on 2011-09-21
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Status tracked in Trunk
Marc Ordinas i Llopis

Bug Description

When starting any program using glproxy on a pandaboard, eglCreateWindowSurface fails with 0x300B (EGL_BAD_NATIVE_WINDOW).

Tested with glcompbench-glproxy, output:
OpenGL ES2.0 backend is selected for rendering
PVR:(Warning): InitContext: ignoring buffer type CBUF_TYPE_PDS_VERT_SECONDARY_PREGEN_BUFFER [777, /eglglue.c]
    glcompbench 2011.08
PVR:(Warning): InitContext: ignoring buffer type CBUF_TYPE_PDS_VERT_SECONDARY_PREGEN_BUFFER [777, /eglglue.c]
Error: eglCreateWindowSurface failed with error: 12299
    OpenGL Information
    GL_VENDOR: Imagination Technologies
    GL_RENDERER: PowerVR SGX 540
    GL_VERSION: OpenGL ES 2.0

Changed in glproxy:
assignee: nobody → Marc Ordinas i Llopis (marcoil)
status: New → In Progress
Marc Ordinas i Llopis (marcoil) wrote :

Things I've found out: One glproxy test, triangle, produces exactly the same error. But another one, egl_tfp, does not. The difference seems to be that egl_tfp creates the window, eglContext and eglSurface before calling glProxyInit, while triangle initializes after calling it.

As glproxy creates an eglContext and an eglSurface during glProxyInit, it's possible that the error comes from the EGL implementation on panda not supporting having different contexts.

Jesse Barker (jesse-barker) wrote :

At the risk of overstating the obvious, the only reason for the error in question to be generated by eglCreateWindowSurface is if the native window handle passed in is not valid (not an actual native window handle, not a window "belonging" to the client, etc.). Trying to create a new surface for a native window handle that already has one is a different error (by the spec). eglMakeCurrent can also generate that error for basically the same reason (let's say you destroyed the native window after creating the EGLSurface, when you call make current it will tell you that it's not valid). I'll get very depressed if someone is actually shipping an implementation that only supports one context per process (obviously only one can be bound to a thread at any given time, but you should be able to have as many as you have memory to track).

Jesse Barker (jesse-barker) wrote :

Are we sure glproxy and the applications in question are actually checking the error state of the GL after each call?

Marc Ordinas i Llopis (marcoil) wrote :

I just tried inverting the initialization sequence in egl_tfp and if glProxyInit is called *before* creating the window then the error occurs.

I'll try a smaller test case…

Marc Ordinas i Llopis (marcoil) wrote :

I've tried a smaller test case that creates two contexts and I can't reproduce the error, glproxy must be doing something that messes EGL up. I'll investigate further…

Jesse Barker (jesse-barker) wrote :

Make sure it's not something silly like an uninitialized variable for the native window handle :-)

Marc Ordinas i Llopis (marcoil) wrote :

I don't think it's an uninitialized variable: In the test program egl_tfp, just changing the call to glProxyInit from where it is (after creating the X window) to an earlier point (before calling eglInitialize) makes the error appear, but I can't see any value changing besides which EGLDisplay is the one for the program and which is internal to glproxy.

I haven't been able to reproduce it with a simple test case either, even after copying all the initialization code from egl_tfp. I'm clearly missing something but I have no idea what.

Marc Ordinas i Llopis (marcoil) wrote :

Revision 36 merged EGL support and removed the initial creation of an EGL context inside glproxy, making this bug disappear.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers