<p dir="ltr">On Sat, Mar 28, 2015 at 6:57 AM, x414e54 <<a href="mailto:x414e54@linux.com">x414e54@linux.com</a>> wrote:<br>
> I am attempting to pass a GL_TEXTURE_2D directly to a Wayland compositor by<br>
> first converting it so an EGLImageKHR and then to a wl_buffer.<br>
><br>
> eglCreateImageKHR appears to work fine but when calling<br>
> glCreateWaylandBufferFromImageWL I get EGL_BAD_MATCH "unsupported image<br>
> format".<br>
><br>
> The GL_TEXTURE_2D is in GL_RGBA format.<br>
><br>
> Is this going to be possible or should I look for an alternative way?</p>
<p dir="ltr">I wouldn't expect this to work at all in general. The glCreateWaylandBufferFromImageWL extension was initially created for nested compositor. The intention was to take buffers recieved by a nested compositor from Wayland client and then hand them directly off to the parent compositor. In other words, the buffers were something that already came from a Wayland client and so handing them off across the Wayland protocol was always safe. This was never intended for passing around arbitrary EGLImages.</p>
<p dir="ltr">Why not? There may be all sorts of tiling, stride, and color format restrictions required by the compositor half of the graphics stack that may not be required for a texture. For instance, if you want to be able to scan out from the buffer directly, the restrictions are usually fairly heavy.</p>
<p dir="ltr">How can you do this?  One way would be to use GBM to allocate your buffer and then import it into egl to render and then talk the wl_drm protocol directly.  However, this is far more complicated than you probably want and, while it will work with mesa, it is not a general solution.</p>
<p dir="ltr">If you gave a more high-level description of what you are trying to do, I may be able to help better.  It's quite possible that there is a fairly simple way to do it.</p>
<p dir="ltr">> I was originally blitting the texture to the default framebuffer and then<br>
> trying to use eglSwapBuffers. But for some reason eglSwapBuffers was<br>
> returning EGL_BAD_SURFACE even though eglMakeCurrent had no errors.</p>
<p dir="ltr">Can you render to it?  That sounds like something is wrong in the way you're setting up your EGLSurface.  Of you can render you should be able to blit.<br>
--Jason</p>