eglCreateWindowSurface fails with error 12299 on pandaboard

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.

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).

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

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…

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…

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

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.

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