Upside down and backwards

[Kristian Høgsberg]

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:
>
>> Hi,
>>
>> 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.

  http://cgit.freedesktop.org/~krh/mesa/log/?h=gbm_surface

Kristian