1. 03 Jul, 2017 1 commit
  2. 12 Jun, 2017 3 commits
  3. 30 Mar, 2017 1 commit
  4. 28 Nov, 2016 1 commit
  5. 21 Nov, 2016 4 commits
  6. 16 Nov, 2016 1 commit
  7. 07 Nov, 2016 6 commits
  8. 03 Nov, 2016 1 commit
  9. 05 Oct, 2016 2 commits
  10. 01 Oct, 2016 1 commit
  11. 15 Aug, 2016 2 commits
    • Pekka Paalanen's avatar
      gl-renderer, simple-dmabuf-v4l: fix dmabuf y-invert · 319397e0
      Pekka Paalanen authored
      Invert the Y_INVERT flag for the EGL import fo dmabufs. This fixes
      weston-simple-dmabuf-intel to show the same image on both GL-composited
      and with direct scanout on a hardware plane. Before, the image would
      y-flip when switching between these two cases. Now the orientation also
      matches the color values written in simple-dmabuf-intel.c.
      
      The GL-renderer uses the OpenGL convention of texture coordinates, where
      the origin is at the bottom-left of an image. This can be observed in
      texture_region() where the texcoords are inverted if y_invert is false,
      since the surface coordinates have origin at top-left.  Both wl_shm and
      dmabuf buffers have origin at the top-left.
      
      When wl_shm buffer is imported with glTexImage2D, it gets inverted
      because glTexImage2D is defined to read in the bottom row first. The shm
      data is top row first. This incidentally also means, that buffer pixel
      0,0 ends up at texture coordinates 0,0. This is now inverted compared to
      the GL coordinate convention, and therefore gl_renderer_attach_shm()
      sets y_inverted to true. This causes texture_region() to NOT invert the
      texcoords. Wayland surface coordinates have origin at top-left, hence
      the double-inversion.
      
      Dmabuf buffers also have the origin at top-left. However, they are
      imported via EGL to GL, where they should get the GL oriented
      coordinates but they do not. It is as if pixel 0,0 ends up at texcoords
      0,0 - the same thing as with wl_shm buffers. Therefore we need to invert
      the invert flag.
      
      Too bad EGL_EXT_image_dma_buf_import does not seem to specify the image
      orientation. The GL spec implied result seems to conflict with the
      reality in Mesa 11.2.2.
      
      I asked about this in the Mesa developer mailing list. The question with
      no answers:
      https://lists.freedesktop.org/archives/mesa-dev/2016-June/120249.html
      and the thread I hijacked to get some answers:
      https://lists.freedesktop.org/archives/mesa-dev/2016-June/120733.html
      which culminated to the conclusion:
      https://lists.freedesktop.org/archives/mesa-dev/2016-June/120955.html
      that supports this patch.
      
      simple-dmabuf-v4l is equally fixed to not add Y_INVERT. There is no
      rational reason to have it, and removing is necessary together with the
      GL-renderer change to keep the image the right way up. This has been
      tested with VIVID.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Quentin Glidic's avatarQuentin Glidic <sardemff7+git@sardemff7.net>
      319397e0
    • Quentin Glidic's avatar
      gl-renderer: Silence maybe-uninitialized warning · d84af7cc
      Quentin Glidic authored
      libweston/gl-renderer.c: In function 'compress_bands':
      libweston/gl-renderer.c:481:6: warning: 'merged' may be used
      uninitialized in this function [-Wmaybe-uninitialized]
         if (!merged) {
               ^
      
      Warning produced by GCC 5.3 and 6.1, with -Og.
      Signed-off-by: Quentin Glidic's avatarQuentin Glidic <sardemff7+git@sardemff7.net>
      Reviewed-by: default avatarYong Bakos <ybakos@humanoriented.com>
      Reviewed-by: default avatarGiulio Camuffo <giuliocamuffo@gmail.com>
      d84af7cc
  12. 11 Aug, 2016 1 commit
  13. 26 Jul, 2016 1 commit
  14. 22 Jul, 2016 5 commits
  15. 27 Jun, 2016 1 commit
    • Armin Krezović's avatar
      gl-renderer: Always setup gl-renderer · 28d240f2
      Armin Krezović authored
      Currently, the gl-renderer setup is being done on per-output
      basis. This isn't desirable when trying to make weston run
      with zero outputs.
      
      When there are no outputs present, there is no surface available
      to attach an EGLContext to with eglMakeCurrent, which makes
      any EGL command fail.
      
      The problem is solved by using EGL_KHR_surfaceless_context to
      bind an EGLContext to EGL_NO_SURFACE, or if that is
      unavailable, creating a dummy PbufferSurface and binding an
      EGLContext to it, so EGL gets set up properly.
      
      v2:
      
      - Move PbufferSurface creation into its own function
      - Introduce a new EGLConfig with EGL_PBUFFER_BIT set
        and use it to create a PbufferSurface
      - Make PbufferSurface attributes definition static
      - Check for return of gl_renderer_setup and terminate
        in case it fails
      - Remove redundant gl_renderer_setup call from
        gl_renderer_output_create
      - Only destroy the dummy surface if it is valid
      
      This patch causes a warning from Mesa when using the i965 driver:
      libEGL warning: FIXME: egl/x11 doesn't support front buffer rendering.
      A bug has been filed about it since it seems to be spurious:
      https://bugs.freedesktop.org/show_bug.cgi?id=96694Signed-off-by: default avatarArmin Krezović <krezovic.armin@gmail.com>
      [Pekka: filed a Mesa bug and added the note in commit msg]
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      28d240f2
  16. 23 Jun, 2016 1 commit
  17. 22 Mar, 2016 1 commit
  18. 14 Jan, 2016 1 commit
  19. 11 Jan, 2016 2 commits
  20. 02 Dec, 2015 1 commit
  21. 20 Nov, 2015 2 commits
  22. 19 Nov, 2015 1 commit