1. 20 Dec, 2019 3 commits
  2. 19 Dec, 2019 1 commit
    • Michel Dänzer's avatar
      xwayland: Create duplicate TrueColor GLXFBConfigs for Composite · 846e81ec
      Michel Dänzer authored and Michel Dänzer's avatar Michel Dänzer committed
      Similar to what is done in Xorg. Not doing this prevented apps from
      using GLX with a Composite visual, e.g. Firefox WebRender or Chromium.
      
      v2:
      * Fix inverted direct_color test, fixes Chromium as well.
      * Drop Composite extension guards, since other Xwayland code calls
        compRedirectWindow/compUnredirectWindow unconditionally anyway.
      
      Closes: xorg/xserver#921
      Fixes: 84692415 "xwayland: Add EGL-backed GLX provider"
      Reviewed-by: Adam Jackson <ajax@redhat.com> # v1
      846e81ec
  3. 17 Dec, 2019 3 commits
  4. 13 Dec, 2019 3 commits
  5. 03 Dec, 2019 1 commit
  6. 28 Nov, 2019 3 commits
    • Olivier Fourdan's avatar
      xwayland: Use multiple window buffers · cd999f08
      Olivier Fourdan authored
      Xwayland takes care of not attaching a new buffer if a frame callback is
      pending.
      
      Yet, the existing buffer (which was previously attached) may still be
      updated from the X11 side, causing unexpected visual glitches to the
      buffer.
      
      Add multiple buffering to the xwl_window and alternate between buffers,
      to leave the Wayland buffer untouched between frame callbacks and avoid
      stuttering or tearing issues.
      
      Closes: xorg/xserver#835
      
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      cd999f08
    • Olivier Fourdan's avatar
      xwayland: Add multiple window buffering support · 1c6f875f
      Olivier Fourdan authored
      
      
      Add a mechanism to create, recycle and destroy window buffers when
      needed.
      
      Typically, this adds a new `xwl_window_buffer` structure which
      represents a buffer for a given Xwayland window.
      
      Each Xwayland window has two different pools of buffers:
      
       - The available buffers pool:
         Those are buffers which where created previously and that have either
         not been submitted to the compositor or submitted and released.
      
       - The unavailable buffers pool:
         Those are typically the buffers which are being used by the
         compositor, awaiting a release.
      
      Initially, an Xwayland window starts with both pools empty. As soon as a
      new buffer is needed, it's either created (if there is none available)
      or picked from the pool of available buffers.
      
      Once submitted to the compositor, the buffer is moved to the pool of
      unavailable buffers. When the corresponding `wl_buffer` is released by
      the compositor, it is moved back to pool of available buffers again to
      be reused when needed.
      
      To avoid keeping too many buffers around doing nothing, a garbage
      collection of older, unused buffers also takes care of disposing the
      buffers being unused for some time.
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      1c6f875f
    • Olivier Fourdan's avatar
      xwayland: Add buffer release callback · 77658741
      Olivier Fourdan authored
      
      
      The API `wl_buffer_add_listener` is misleading in the sense that there
      can be only one `wl_buffer` release callback, and trying to add a new
      listener when once is already in place will lead to a protocol error.
      
      The Xwayland EGL backends may need to set up their own `wl_buffer`
      release listener, meaning that there is no way to our own `wl_buffer`
      release callback.
      
      To avoid the problem, add our own callback API to be notified when the
      `wl_buffer` associated with an `xwl_pixmap` is released, triggered from
      the different `xwl_pixmap` implementations.
      
      Also update the Present code to use the new buffer release callback API.
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      77658741
  7. 19 Nov, 2019 1 commit
    • Olivier Fourdan's avatar
      xwayland: Do not discard frame callbacks on allow commits · 66da95a1
      Olivier Fourdan authored and Olivier Fourdan's avatar Olivier Fourdan committed
      
      
      Currently, when a X11 client (usually the X11 window manager from a
      Wayland compositor) changes the value of the X11 property
      `_XWAYLAND_ALLOW_COMMITS` from `false` to `true`, all pending frame
      callbacks on the window are discarded so that the commit occurs
      immediately.
      
      Weston uses that mechanism to prevent the content of the window from
      showing before it's ready when mapping the window initially, but
      discarding the pending frame callbacks has no effect on the initial
      mapping of the X11 window since at that point there cannot be any frame
      callback on a surface which hasn't been committed yet anyway.
      
      However, discarding pending frame callbacks can be problematic if we
      were to use the same `_XWAYLAND_ALLOW_COMMITS` mechanism to prevent
      damages to be posted before the X11 toplevel is updated completely
      (including the window decorations from the X11 window manager).
      
      Remove the portion of code discarding the pending frame callback,
      Xwayland should always wait for a pending frame callback if there's one
      before posting new damages.
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      xorg/xserver!333
      66da95a1
  8. 08 Nov, 2019 4 commits
  9. 07 Nov, 2019 1 commit
    • Dor Askayo's avatar
      xwayland: clear pixmaps after creation in rootless mode · 0e9a0c20
      Dor Askayo authored and Michel Dänzer's avatar Michel Dänzer committed
      
      
      When a pixmap is created with a backing FBO, the FBO should be cleared
      to avoid rendering uninitialized memory. This could happen when the
      pixmap is rendered without being filled in its entirety.
      
      One example is when a top-level window without a background is
      resized. The pixmap would be reallocated to prepare for more pixels,
      but uninitialized memory would be rendered in the resize offset until
      the client sends a frame that fills these additional pixels.
      
      Another example is when a new top-level window is created without a
      background. Uninitialized memory would be rendered after the pixmap is
      allocated and before the client sends its first frame.
      
      This issue is only apparent in OpenGL implementations that don't zero
      the VRAM of allocated buffers by default, such as RadeonSI.
      Signed-off-by: Dor Askayo's avatarDor Askayo <dor.askayo@gmail.com>
      Closes: #636
      
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      0e9a0c20
  10. 06 Nov, 2019 1 commit
  11. 05 Nov, 2019 1 commit
  12. 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>
      741bd734
  13. 16 Oct, 2019 1 commit
  14. 12 Oct, 2019 12 commits
  15. 02 Oct, 2019 1 commit
  16. 23 Sep, 2019 2 commits
  17. 10 Sep, 2019 1 commit
    • Carlos Garnacho's avatar
      xwayland: Allow passing a fd for set up clients · 7ad1d0d3
      Carlos Garnacho authored and Adam Jackson's avatar Adam Jackson committed
      
      
      This FD also triggers the "wait for WM_S0" paths, so that the
      compositor may set up a "maintenance line" for Xwayland, for
      services that are essential to run before any client (eg. xrdb).
      Those services would use this FD, disguised as an extra display
      connection.
      
      This -initfd can be seen as a generalization of -wm, a Wayland
      compositor may use -initfd to launch its WM and any other clients
      that should start up, or it may use -wm as a dedicated connection for
      the WM and optionally use -initfd for the misc. startup clients.
      
      If either of -wm or -initfd is passed, Xwayland will expect a selection
      notification on WM_S0 before incorporating the FDs in -listen to the
      poll list.
      
      Also, correct a minor typo in the listenfd argument output,
      give → given.
      Signed-off-by: Carlos Garnacho's avatarCarlos Garnacho <carlosg@gnome.org>
      7ad1d0d3