Upside down and backwards
hoegsberg at gmail.com
Wed Mar 7 08:34:03 PST 2012
On Mon, Mar 5, 2012 at 2:42 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Sun, 4 Mar 2012 20:37:48 -0800
> Mandeep Singh Baines <msb at chromium.org> wrote:
>> I have recently started playing around with EGL_PLATFORM=drm. Using
>> eglkms.c and compositor-drm.c as examples, I've been able to port some
>> simple EGL/GLESv2 applications without much effort. But the one weird
>> thing is that everything gets rendered upside down and backwards. I
>> guess I could solve this with the projection matrix but just wondering
>> why I'm getting this effect. How does compositor-drm deal with this.
> Look for WL_OUTPUT_FLIPPED in weston.
> I guess and if I remember right, flipped y-axis is because OpenGL
> back/front buffer of a window has origin at top-left with y growing
> down, but FBOs have origin at bottom-left with y growing up. Or maybe
> it was vice versa, I didn't check.
I'm actually not sure about this. For a while I thought that GL
framebuffer objects had a different coordinate system (origin in upper
left), but Robert Bragg recently pointed out to me that that was just a
mesa optimization. Which could be true and I wasn't able to find
anything in the FBO spec about the coordinate system.
Either way, there isn't currently anything you can do, except render
upside down. We do have a new interface planned, that will let you
create a struct gbm_surface, which you can then create an EGLSurface
from. That way it's going to be a "system fbo" internally in mesa and
the coordinate system is going to what you expect. It will also
remove the need for the surfaceless extension (since now we have a
real EGLSurface). The API will let you "lock" the surface frontbuffer
after a swap, which gives you a gbm_bo which you can then pageflip to.
It's going to require mesa master, but I hope we can land it within
the next couple of weeks.
More information about the wayland-devel