Image y-inversion mess with dmabufs
Submitted by Pekka Paalanen @pq
Assigned to Micah Fedke @fedke.m
Description
I noticed that weston-simple-dmabuf-intel shows the image a different side up on GL vs. direct scanout. The I noticed the following facts:
- GL-renderer must be assuming the OpenGL texture coordinate orientation, where origin is bottom-left
- wl_shm upload path (glTexImage2D) sets y_invert=true
- y_invert=true causes the texcoords to be NOT inverted, and vice versa
- wl_drm path just asks EGL for the y_invert flag and Just Works
- simple-dmabuf-intel does not set Y_INVERT
- simple-dmabuf-v4l sets Y_INVERT
- compositor-drm ignores the y-invert flag from dmabufs (this is a bug for sure)
- EGL_EXT_image_dma_buf_import does not specify the resulting image orientation
- it looks like dmabuf import via EGLImage uses the inverted orientation compared to GL, that is, the same as what wl_shm ends up with when it (un)intentionally inverts with glTexImage2D
If Mesa is correct, then the dmabuf import in Weston sets y_invert wrong. This is supported by the shown image orientation when simple-dmabuf-intel is being scanned out directly, as it does not set Y_INVERT and compositor-drm does not handle Y_INVERT.
But if that is true, then simple-dmabuf-v4l must also be incorrect in setting the Y_INVERT flag. If GL-renderer is fixed, simple-dmabuf-v4l image will turn upside-down, except for the direct scanout path which ignores the flag.