1. 06 Nov, 2019 1 commit
  2. 05 Nov, 2019 1 commit
  3. 04 Nov, 2019 1 commit
    • Hans de Goede's avatar
      glamor/xwayland: Define EGL_NO_X11 · 741bd734
      Hans de Goede authored
      Define EGL_NO_X11 everywhere were we also define MESA_EGL_NO_X11_HEADERS,
      EGL_NO_X11 is the MESA_EGL_NO_X11_HEADERS equivalent for the egl headers
      shipped with libglvnd.
      This fixes the xserver not building with the libglvnd-1.2.0 headers:
      In file included from /usr/include/EGL/eglplatform.h:128,
                       from /usr/include/epoxy/egl_generated.h:11,
                       from /usr/include/epoxy/egl.h:46,
                       from glamor_priv.h:43,
                       from glamor_composite_glyphs.c:25:
      /usr/include/X11/Xlib.h:222:2: error: conflicting types for 'GC'
        222 | *GC;
            |  ^~
      In file included from glamor.h:34,
                       from glamor_priv.h:32,
                       from glamor_composite_glyphs.c:25:
      ../include/gcstruct.h:282:3: note: previous declaration of 'GC' was here
        282 | } GC;
            |   ^~
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
  4. 23 Sep, 2019 2 commits
  5. 23 Jul, 2019 1 commit
    • Olivier Fourdan's avatar
      xwayland: Do not free a NULL GBM bo · d9ec5250
      Olivier Fourdan authored
      Both `gbm_bo_create()` and `gbm_bo_create_with_modifiers()` can fail and
      return `NULL`.
      If that occurs, `xwl_glamor_gbm_create_pixmap()` will not create a
      pixmap for the (NULL) GBM bo, but would still try to free the bo which
      leads to a crash in mesa:
        #7  <signal handler called>
        #8  in gbm_bo_destroy (bo=0x0) at ../src/gbm/main/gbm.c:439
        #9  in xwl_glamor_gbm_create_pixmap () at xwayland-glamor-gbm.c:245
        #10 in ProcCreatePixmap () at dispatch.c:1440
        #11 in Dispatch () at dispatch.c:478
        #12 in dix_main () at main.c:276
      To avoid the crash, only free the GBM bo if not `NULL`.
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
      Bugzilla: https://bugzilla.redhat.com/1729925
  6. 28 May, 2019 2 commits
    • Olivier Fourdan's avatar
      xwayland: check `glamor_set_pixmap_texture()` status · 48f4ab75
      Olivier Fourdan authored and Adam Jackson's avatar Adam Jackson committed
      With `glamor_set_pixmap_texture()` returning its status, remove the hack
      and use the return value.
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
    • Olivier Fourdan's avatar
      xwayland: Check status in GBM pixmap creation · fc6380a1
      Olivier Fourdan authored and Adam Jackson's avatar Adam Jackson committed
      The current code in `xwl_glamor_gbm_create_pixmap_for_bo()` may fail in
      several cases that are not checked for:
       - `eglCreateImageKHR()` may have failed to create the image,
       - `glEGLImageTargetTexture2DOES()` may fail and set an error,
       - `glamor_set_pixmap_texture()` may fail for very large pixmaps
          because the corresponding FBO could not be created.
      Trying to upload content to a pixmap with no texture will crash Mesa,
      glamor and Xwayland, e.g.:
        XXX fail to create fbo.
        (EE) Backtrace:
        (EE) 0: Xwayland (OsSigHandler+0x29)
        (EE) 1: libpthread.so.0 (funlockfile+0x50)
        (EE) 2: libc.so.6 (__memmove_avx_unaligned_erms+0x215)
        (EE) 3: dri/i965_dri.so (_mesa_format_convert+0xab3)
        (EE) 4: dri/i965_dri.so (_mesa_texstore+0x205)
        (EE) 5: dri/i965_dri.so (store_texsubimage+0x28c)
        (EE) 6: dri/i965_dri.so (intel_upload_tex+0x13b)
        (EE) 7: dri/i965_dri.so (texture_sub_image+0x134)
        (EE) 8: dri/i965_dri.so (texsubimage_err+0x150)
        (EE) 9: dri/i965_dri.so (_mesa_TexSubImage2D+0x48)
        (EE) 10: Xwayland (glamor_upload_boxes+0x246)
        (EE) 11: Xwayland (glamor_copy+0x4d1)
        (EE) 12: Xwayland (miCopyRegion+0x96)
        (EE) 13: Xwayland (miDoCopy+0x43c)
        (EE) 14: Xwayland (glamor_copy_area+0x24)
        (EE) 15: Xwayland (damageCopyArea+0xba)
        (EE) 16: Xwayland (compCopyWindow+0x31c)
        (EE) 17: Xwayland (damageCopyWindow+0xd3)
        (EE) 18: Xwayland (miResizeWindow+0x7b7)
        (EE) 19: Xwayland (compResizeWindow+0x3a)
        (EE) 20: Xwayland (ConfigureWindow+0xa96)
        (EE) 21: Xwayland (ProcConfigureWindow+0x7d)
        (EE) 22: Xwayland (Dispatch+0x320)
        (EE) 23: Xwayland (dix_main+0x366)
        (EE) 24: libc.so.6 (__libc_start_main+0xf3)
        (EE) 25: Xwayland (_start+0x2e)
        Fatal server error:
        (EE) Caught signal 11 (Segmentation fault). Server aborting
      Check for the possible cases of failure above and fallback to the
      regular glamor pixmap creation when an error is detected.
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Closes: xorg/xserver#661
  7. 25 Oct, 2018 1 commit
    • Olivier Fourdan's avatar
      xwayland: do not crash if `gbm_bo_create()` fails · 036794be
      Olivier Fourdan authored and Adam Jackson's avatar Adam Jackson committed
      The function `xwl_glamor_gbm_create_pixmap()` first creates a buffer
      objects and then creates the xwl_pixmap from it.
      However, `xwl_glamor_gbm_create_pixmap_for_bo()` is not called if the
      buffer object creation fails, and `xwl_glamor_gbm_create_pixmap()`
      simply returns `glamor_create_pixmap()`.
      The problem with this is that if `xwl_glamor_gbm_create_pixmap_for_bo()`
      is not called then neither is `xwl_pixmap_set_private()` and further
      calls to `xwl_pixmap_get()` will return NULL and cause a NULL pointer
      dereference if the return value is not checked:
        #0  xwl_glamor_gbm_get_wl_buffer_for_pixmap ()
            at hw/xwayland/xwayland-glamor-gbm.c:248
        #1  xwl_window_post_damage () at hw/xwayland/xwayland.c:697
        #2  xwl_display_post_damage () at hw/xwayland/xwayland.c:759
        #3  block_handler () at hw/xwayland/xwayland.c:890
        #4  BlockHandler () at dix/dixutils.c:388
        #5  WaitForSomething () at os/WaitFor.c:201
        #6  Dispatch () at dix/dispatch.c:421
        #7  dix_main () at dix/main.c:276
        #8  __libc_start_main () at ../csu/libc-start.c:308
        #9  _start ()
        (gdb) print xwl_pixmap
        $1 = (struct xwl_pixmap *) 0x0
      Make sure we check for `xwl_pixmap_get()` returned value where relevant
      and fail gracefully if this is the case.
      See also: https://gitlab.gnome.org/GNOME/mutter/issues/340
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Marco Trevisan's avatarMarco Trevisan <mail@3v1n0.net>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  8. 05 Oct, 2018 1 commit
  9. 01 Oct, 2018 1 commit
    • Olivier Fourdan's avatar
      xwayland: search for a render node to use · 36189449
      Olivier Fourdan authored
      wl_drm's protocol "device" event provides the path to the DRM device,
      which may not be a render node, thus causing Xwayland to fall back to
      DRM authentication which may fail if the user has switched to another
      VT while Xwayland is starting.
      Search for a render node corresponding to the given DRM device and try
      to use it instead, as render nodes do not need DRM authentication and
      Xwayland can make use of them if it can find one.
      Closes: https://bugs.freedesktop.org/108038
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
  10. 28 Sep, 2018 1 commit
    • Adam Jackson's avatar
      glamor_egl: Don't initialize on llvmpipe · 0a9415cf
      Adam Jackson authored and Adam Jackson's avatar Adam Jackson committed
      Mesa started supporting GL_OES_EGL_image on llvmpipe in 17.3, after this
          commit bbdeddd5fd0b797e1e281f058338b3da4d98029d
          Author: Gurchetan Singh <gurchetansingh@chromium.org>
          Date:   Tue Aug 1 14:49:33 2017 -0700
              st/dri: add drisw image extension
      That's pretty cool, but it means glamor now thinks it can initialize on
      llvmpipe. This is almost certainly not what anyone wants, as glamor on
      llvmpipe is pretty much uniformly slower than fb.
      This fixes both Xorg and Xwayland to refuse glamor in such a setup.
      Xephyr is left alone, both because glamor is not the default there and
      because Xephyr+glamor+llvmpipe is one of the easier ways to get xts to
      exercise glamor.
      The (very small) downside of this change is that you lose DRI3 support.
      This wouldn't have helped you very much (since an lp glamor blit is
      slower than a pixman blit), but it would eliminate the PutImage overhead
      for llvmpipe's glXSwapBuffers. A future change should add DRI3 sup...
  11. 27 Jun, 2018 1 commit
    • Lyude Paul's avatar
      glamor: Unbreak glamor_fd_from_pixmap() · 186a21c4
      Lyude Paul authored
      When support for allocating GBM BOs with modifiers was added,
      glamor_fd_from_pixmap() was changed so that it would return an error if
      it got a bo with modifiers set from glamor_fds_from_pixmap(). The
      problem is that on systems that support BOs with modifiers,
      glamor_fds_from_pixmap() will always return BOs with modifiers.
      This means that glamor_fd_from_pixmap() was broken entirely, which broke
      a number of other things including glamor_shareable_fd_from_pixmap(),
      which meant that modesetting using multiple GPUs with the modesetting
      DDX was also broken. Easy reproducer:
      - Find a laptop with DRI prime that has outputs connected to the
        dedicated GPU and integrated GPU
      - Try to enable one display on each using the modesetting DDX
      - Fail
      Since there isn't a way to ask for no modifiers from
      glamor_fds_from_pixmap, we create a shared _glamor_fds_from_pixmap()
      function used by both glamor_fds_from_pixmap() and
      glamor_fd_from_pixmap() that calls down to the appropriate
  12. 21 Jun, 2018 6 commits
  13. 08 Jun, 2018 1 commit
  14. 08 May, 2018 1 commit
  15. 24 Apr, 2018 2 commits
    • Lyude Paul's avatar
      xwayland: Add glamor egl_backend for EGLStreams · 54ac0971
      Lyude Paul authored and Adam Jackson's avatar Adam Jackson committed
      This adds initial support for displaying Xwayland applications through
      the use of EGLStreams and nvidia's custom wayland protocol by adding
      another egl_backend driver. This also adds some additional egl_backend
      hooks that are required to make things work properly.
      EGLStreams work a lot differently then the traditional way of handling
      buffers with wayland. Unfortunately, there are also a LOT of various
      pitfalls baked into it's design that need to be explained.
      This has a very large and unfortunate implication: direct rendering is,
      for the time being at least, impossible to do through EGLStreams. The
      main reason being that the EGLStream spec mandates that we lose the
      entire color buffer contents with each eglSwapBuffers(), which goes
      against X's requirement of not losing data with pixmaps.  no way to use
      an allocated EGLSurface as the storage for glamor rendering like we do
      with GBM, we have to rely on blitting each pixmap to it's respective
      EGLSurface producer each frame. In order to pull this off, we add two
      different additional egl_backend hooks that GBM opts out of
      - egl_backend.allow_commits for holding off displaying any EGLStream
        backed pixmaps until the point where it's stream is completely
        initialized and ready for use
      - egl_backend.post_damage for blitting the content of the EGLStream
        surface producer before Xwayland actually damages and commits the
        wl_surface to the screen.
      The other big pitfall here is that using nvidia's wayland-eglstreams
      helper library is also not possible for the most part. All of it's API
      for creating and destroying streams rely on being able to perform a
      roundtrip in order to bring each stream to completion since the wayland
      compositor must perform it's job of connecting a consumer to each
      EGLstream. Because Xwayland has to potentially handle both responding to
      the wayland compositor and it's own X clients, the situation of the
      wayland compositor being one of our X clients must be considered. If we
      perform a roundtrip with the Wayland compositor, it's possible that the
      wayland compositor might currently be connected to us as an X client and
      thus hang while both Xwayland and the wayland compositor await responses
      from eachother. To avoid this, we work directly with the wayland
      protocol and use wl_display_sync() events along with release() events to
      set up and destroy EGLStreams asynchronously alongside handling X
      Additionally, since setting up EGLStreams is not an atomic operation we
      have to take into consideration the fact that an EGLStream can
      potentially be created in response to a window resize, then immediately
      deleted due to another pending window resize in the same X client's
      pending reqests before Xwayland hits the part of it's event loop where
      we read from the wayland compositor. To make this even more painful, we
      also have to take into consideration that since EGLStreams are not
      atomic that it's possible we could delete wayland resources for an
      EGLStream before the compositor even finishes using them and thus run
      into errors. So, we use quite a bit of tracking logic to keep EGLStream
      objects alive until we know the compositor isn't using them (even if
      this means the stream outlives the pixmap it backed).
      While the default backend for glamor remains GBM, this patch exists for
      users who have had to deal with the reprecussion of their GPU
      manufacturers ignoring the advice of upstream and the standardization of
      GBM across most major GPU manufacturers. It is not intended to be a
      final solution to the GBM debate, but merely a baindaid so our users
      don't have to suffer from the consequences of companies avoiding working
      upstream. New drivers are strongly encouraged not to use this as a
      backend, and use GBM like everyone else. We even spit this out as an
      error from Xwayland when using the eglstream backend.
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Acked-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
    • Lyude Paul's avatar
      xwayland: Decouple GBM from glamor · 1545e2db
      Lyude Paul authored and Adam Jackson's avatar Adam Jackson committed
      This takes all of the gbm related code in wayland-glamor.c and moves it
      into it's own EGL backend for Xwayland, xwayland-glamor-gbm.c.
      Additionally, we add the egl_backend struct into xwl_screen in order to
      provide hooks for alternative EGL backends such as nvidia's EGLStreams.
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
  16. 10 Apr, 2018 5 commits
  17. 28 Mar, 2018 1 commit
  18. 09 Mar, 2018 1 commit
  19. 05 Mar, 2018 4 commits
  20. 07 Nov, 2017 1 commit
  21. 13 Sep, 2017 1 commit
  22. 03 Jun, 2017 1 commit
  23. 09 Mar, 2017 1 commit
  24. 06 Mar, 2017 1 commit
  25. 05 Oct, 2016 1 commit