1. 20 Dec, 2019 4 commits
  2. 19 Dec, 2019 1 commit
    • Michel Dänzer's avatar
      xwayland: Create duplicate TrueColor GLXFBConfigs for Composite · 846e81ec
      Michel Dänzer authored
      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. 12 Dec, 2019 1 commit
    • dslater38's avatar
      XWin: Fix infinite loop in GetShift() · 71c3a971
      dslater38 authored
      GetShift(int mask) can be called with mask==0, causing
      it to go into an infinite loop.
      
      Note: GetShift(mask) will return 0 for a mask of
      both 0 and -1. The assumption is that if mask == 0,
      then the corresponding bits for which we're calculating
      the shift, are also 0.
      71c3a971
  6. 11 Dec, 2019 1 commit
  7. 03 Dec, 2019 1 commit
  8. 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
  9. 26 Nov, 2019 2 commits
  10. 25 Nov, 2019 5 commits
  11. 22 Nov, 2019 2 commits
  12. 21 Nov, 2019 2 commits
  13. 19 Nov, 2019 2 commits
    • Aaron Plattner's avatar
      os: Don't crash in AttendClient if the client is gone · 4308f5d3
      Aaron Plattner authored
      If a client is in the process of being closed down, then its client->osPrivate
      pointer will be set to NULL by CloseDownConnection. This can cause a crash if
      freeing the client's resources results in a call to AttendClient. For example,
      if the client has a pending sync fence:
      
       Thread 1 "X" received signal SIGSEGV, Segmentation fault.
       AttendClient (client=0x5571c4aed9a0) at ../os/connection.c:942
       (gdb) bt
       #0  AttendClient (client=0x5571c4aed9a0) at ../os/connection.c:942
       #1  0x00005571c3dbb865 in SyncAwaitTriggerFired (pTrigger=<optimized out>) at ../Xext/sync.c:694
       #2  0x00005571c3dd5749 in miSyncDestroyFence (pFence=0x5571c5063980) at ../miext/sync/misync.c:120
       #3  0x00005571c3dbbc69 in FreeFence (obj=<optimized out>, id=<optimized out>) at ../Xext/sync.c:1909
       #4  0x00005571c3d7a01d in doFreeResource (res=0x5571c506e3d0, skip=skip@entry=0) at ../dix/resource.c:880
       #5  0x00005571c3d7b1dc in FreeClientResources (client=0x5571c4aed9a0) at ../dix/...
      4308f5d3
    • Olivier Fourdan's avatar
      xwayland: Do not discard frame callbacks on allow commits · 66da95a1
      Olivier Fourdan authored
      
      
      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
  14. 18 Nov, 2019 1 commit
  15. 15 Nov, 2019 1 commit
  16. 13 Nov, 2019 4 commits
  17. 11 Nov, 2019 4 commits
    • Alex Goins's avatar
      modesetting: Implement ms_covering_randr_crtc() for ms_present_get_crtc() · 562c7888
      Alex Goins authored
      
      
      ms_present_get_crtc() returns an RRCrtcPtr, but derives it from a xf86CrtcPtr
      found via ms_dri2_crtc_covering_drawable()=>ms_covering_crtc(). As a result, it
      depends on all associated DIX ScreenRecs having an xf86CrtcConfigPtr DDX
      private.
      
      Some DIX ScreenRecs don't have an xf86CrtcConfigPtr DDX private, but do have an
      rrScrPrivPtr DDX private. Given that we can derive all of the information we
      need from RandR, we can support these screens by avoiding the use of xf86Crtc.
      This change implements an RandR-based path for ms_present_get_crtc(), allowing
      drawables to successfully fall back to syncing to the primary output, even if
      the slave doesn't have an xf86CrtcConfigPtr DDX private.
      
      Without this change, if a slave doesn't have an xf86CrtcConfigPtr DDX private,
      drawables will fall back to 1 FPS if they overlap an output on that slave.
      Signed-off-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
      562c7888
    • Alex Goins's avatar
      modesetting: Fix ms_covering_crtc() segfault with non-xf86Crtc slave · 797e7a0c
      Alex Goins authored
      
      
      DIX ScreenRecs don't necessarily have an xf86CrtcConfigPtr DDX private.
      ms_covering_crtc() assumes that they do, which can result in a segfault.
      
      Update ms_covering_crtc() to check the XF86_CRTC_CONFIG_PTR() returned pointer
      before dereferencing it. This will still mean that ms_covering_crtc() can't fall
      back to the primary output when a drawable overlaps a slave output (going to the
      1 FPS default instead), but it won't segfault.
      Signed-off-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
      797e7a0c
    • Alex Goins's avatar
      modesetting: Fix ms_covering_crtc() segfault with non-modesetting slave primary · 3ef9029a
      Alex Goins authored
      
      
      ms_covering_crtc() uses RRFirstOutput() to determine a primary output to fall
      back to if a drawable is overlapping a slave output.
      
      If the primary output is a slave output, RRFirstOutput() will return a slave
      output even if passed a master ScreenPtr. ms_covering_crtc() dereferences the
      output's devPrivate, which is invalid for non-modesetting outputs, and can
      crash.
      
      Changing RRFirstOutput() could have unintended side effects for other callers,
      so this change replaces the call to RRFirstOutput() with ms_first_output().
      ms_first_output() ignores the primary output if it doesn't match the given
      ScreenPtr, choosing the first connected output instead.
      Signed-off-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
      3ef9029a
    • Alex Goins's avatar
      randr: Fix RRCrtcDetachScanoutPixmap() segfault during server teardown · c82f8143
      Alex Goins authored
      
      
      During server teardown, mrootdraw is NULL, which can cause segfaults if
      master->Stop{,Flipping}PixmapTracking() don't do NULL checking. In this case we
      shouldn't need to do master->Stop{,Flipping}PixmapTracking() anyway, so just
      skip it.
      Signed-off-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
      c82f8143