1. 07 Aug, 2015 2 commits
    • Aaron Plattner's avatar
      compositor: Fix GL_EXT_x11_sync_object race condition · 9df6cda3
      Aaron Plattner authored
      The compositor maintains a ring of shared fences with the X server in order to
      properly synchronize rendering between the X server and the compositor's GPU
      channel.  When all of the fences have been used, the compositor needs to reset
      one so that it can be reused.  It does this by first waiting on the CPU for the
      fence to become triggered, and then sending a request to the X server to reset
      the fence.
      If the compositor's GPU channel is busy processing other work (e.g. the desktop
      switcher animation), then the X server may process the reset request before the
      GPU has consumed the fence.  This causes the GPU channel to hang.
      Fix the problem by having the compositor's GPU channel trigger its own fence
      after waiting for the X server's fence.  Wait for that fence on the CPU before
      sending the reset request to the X server.  This ensures that the GPU has
      consumed the X11 fence before the server resets it.
      Signed-off-by: default avatarAaron Plattner <aplattner@nvidia.com>
    • Rui Matos's avatar
      compositor: Add support for GL_EXT_x11_sync_object · 39763d4a
      Rui Matos authored
      If GL advertises this extension we'll use it to synchronize X with GL
      rendering instead of relying on the XSync() behavior with open source
      Some driver bugs were uncovered while working on this so if we have
      had to reboot the ring a few times, something is probably wrong and
      we're likely to just make things worse by continuing to try.  Let's
      err on the side of caution, disable ourselves and fallback to the
      XSync() path in the compositor.
  2. 05 Aug, 2015 5 commits
  3. 01 Aug, 2015 1 commit
  4. 30 Jul, 2015 1 commit
    • Rui Matos's avatar
      window: Remove fullscreen_after_placement special case · 07f533f6
      Rui Matos authored
      This was introduced in commit c6793d47
      to prevent window self-maximisation. It turns out that that bug seems
      to have been fixed meanwhile in a different way since the reproducer
      in https://bugzilla.gnome.org/show_bug.cgi?id=461927#c37 now works
      fine with this special handling removed.
      In fact, failing to set window->fullscreen immediately when loading
      the initial set of X properties causes us to create a UI frame for a
      window that sets _NET_WM_STATE_FULLSCREEN.
      This, in turn, might cause the fullscreen constrain code to fail if
      the window also sets min_width/min_height size hints to be the monitor
      size since the UI frame size added to those makes the rectangle too
      big to fit the monitor. If the window doesn't set these hints, we
      fullscreen it but the window will get sized such that the UI frame is
      taken into account while it really shouldn't (see the reproducer
  5. 23 Jul, 2015 6 commits
  6. 22 Jul, 2015 1 commit
  7. 21 Jul, 2015 2 commits
  8. 20 Jul, 2015 6 commits
  9. 16 Jul, 2015 9 commits
  10. 15 Jul, 2015 7 commits