Upside down and backwards

[Mandeep Singh Baines]

Kristian Høgsberg (hoegsberg at gmail.com) wrote:
> 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

Thanks much Pekka and Kristian,

That confirms what I was thinking. I was hoping there was a magic
flip_y bit in drmModeAddFB or in the buffer creation somewhere.

Luckily whoever wrote the code for our projection matrix and shader added
a flip_y flag so I've made use of that. gbm_surface sounds great. I'll
definitely keep my eye out for that. (If you can, it would rock if you
could CC me on those patches so I definitely don't miss them.) I'm more
than happy to backport so no issues there. But I'll try to plan around
with the code in your branch till then.

Anyway, huge fan of this work. Despite the quirks of EGL_PLATFORM=drm, its
been surprisingly easy to port to. The quirks (no system fbo, no swapbuffers)
actually gives power/control that would be interesting to take advantage of.
But having system surfaces and SwapBuffers would reduce porting effort and
#ifdefs. If its easy to port to, I can see a lot of appliance-type
applications like xbmc being ported to run sans-X11 with EGL_PLATFORM=drm.

Regards,
Mandeep