Upside down and backwards
Mandeep Singh Baines
msb at chromium.org
Sun Mar 18 15:08:04 PDT 2012
On Wed, Mar 7, 2012 at 8:34 AM, 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
I think you could remove the need for the surfaceless extension even
now. In Chromium, we use a 1x1 Pbuffer surface for such contexts.
> 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
More information about the wayland-devel
mailing list