1. 07 Nov, 2016 5 commits
  2. 03 Nov, 2016 1 commit
  3. 05 Oct, 2016 2 commits
  4. 01 Oct, 2016 1 commit
  5. 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
  6. 11 Aug, 2016 1 commit
  7. 26 Jul, 2016 1 commit
  8. 22 Jul, 2016 5 commits
  9. 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
  10. 23 Jun, 2016 1 commit
  11. 22 Mar, 2016 1 commit
  12. 14 Jan, 2016 1 commit
  13. 11 Jan, 2016 2 commits
  14. 02 Dec, 2015 1 commit
  15. 20 Nov, 2015 2 commits
  16. 19 Nov, 2015 1 commit
  17. 21 Aug, 2015 1 commit
  18. 14 Aug, 2015 2 commits
    • Pekka Paalanen's avatar
      gl-renderer: add dmabuf import · a3525802
      Pekka Paalanen authored
      Import dmabuf as an EGLImage, and hold on to the EGLImage until we are
      signalled a content change. On content change, destroy the EGLImage and
      re-import to trigger GPU cache flushes.
      
      We hold on to the EGLImage as long as possible just in case the client
      does other imports that might later make re-importing fail.
      
      As dmabuf protocol uses drm_fourcc codes, we need libdrm for
      drm_fourcc.h. However, we are not doing any libdrm function calls, so
      there is no new need to link to libdrm.
      
      RFCv1 changes:
      - fix error if dmabuf exposed unsupported
      - always use GL_TEXTURE_EXTERNAL_OES with dmabuf
      
      v2 changes:
      - improve support check and error handling
      - hold on to the imported EGLImage to avoid the dmabuf becoming
        unimportable in the future
      - send internal errors with linux_dmabuf_buffer_send_server_error()
      - import EGL_EXT_image_dma_buf_import extension headers
      - use heuristics to decide between GL_TEXTURE_2D and
        GL_TEXTURE_EXTERNAL_OES
      - add comment about Mesa requirements
      - change y-invert from per-plane boolean to per-buffer flag
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Signed-off-by: Louis-Francis Ratté-Boulianne's avatarLouis-Francis Ratté-Boulianne <lfrb@collabora.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      a3525802
    • Louis-Francis Ratté-Boulianne's avatar
      gl-renderer: introduce struct egl_image · 534defdf
      Louis-Francis Ratté-Boulianne authored
      This is a reference-counted holder of an EGLImage. For now, direct
      EGLImage usage is simply converted to use egl_image. Use of reference
      counting will come in a later patch.
      
      v2:
      - this is a new patch, split from gl-renderer dmabuf import support
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      534defdf
  19. 17 Jul, 2015 1 commit
    • Derek Foreman's avatar
      input: Pass the appropriate pointer type to bindings instead of a seat · 8ae2db5b
      Derek Foreman authored
      Normally we need to check if a seat's [device_type]_count is > 0 before
      we can use the associated pointer.  However, in a binding you're
      guaranteed that the seat has a device of that type.  If we pass in
      that type instead of the seat, it's obvious we don't have to test it.
      
      The bindings can still get the seat pointer via whatever->seat if they
      need it.
      
      This is preparation for a follow up patch that prevents direct access
      to seat->device_type pointers, and this will save us a few tests at
      that point.
      Reviewed-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Signed-off-by: default avatarDerek Foreman <derekf@osg.samsung.com>
      8ae2db5b
  20. 16 Jun, 2015 2 commits
  21. 15 Jun, 2015 1 commit
  22. 22 May, 2015 1 commit
  23. 18 May, 2015 2 commits
  24. 08 Apr, 2015 2 commits