1. 26 Sep, 2019 1 commit
  2. 21 Aug, 2019 1 commit
    • Adam Jackson's avatar
      miext/sync: Fix needless ABI change · 194ba387
      Adam Jackson authored
      The initialized field was added in:
          commit 82f01ad7869e3f2be51e41a8246dab5982bbc36a
          Author: Alex Goins <agoins@nvidia.com>
          Date:   Wed Apr 10 13:48:02 2019 -0500
              xsync: Add resource inside of SyncCreate, export SyncCreate
      But it added this field not at the end of SyncObject. It may not have
      been _usefully_ possible to create those from another extension prior to
      that commit, but that's still an ABI-incompatible change.
  3. 15 Aug, 2019 1 commit
    • Olivier Fourdan's avatar
      meson: Build miext/sync for Xwayland · e8a85ba8
      Olivier Fourdan authored
      When using the Meson build system, miext/sync would be build only for
      As a result, when building with Meson without DRI3 enabled, Xwayland
      would fail to link because `miSyncShmScreenInit()` is nowhere to be
      Make sure to build miext/sync for either DRI3 or Xwayland.
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
  4. 02 May, 2019 1 commit
  5. 17 Apr, 2019 1 commit
    • Alex Goins's avatar
      xsync: Add resource inside of SyncCreate, export SyncCreate · 7f962c70
      Alex Goins authored
      As shown by DRI3 adding the SyncCreateFenceFromFD() function, extensions may
      want to create a fence, then initialize it in their own way. This currently
      can't be done without adding a function directly to Xext/sync.c due to the fact
      that the RTFence resource type is private and there is no external interface to
      add to it.
      To facilitate other X extensions creating fences and initializing them, this
      change exports SyncCreate() and adds the resource directly within it. Callers no
      longer need to call AddResource() after SyncCreate(), they only need to
      initialize the SyncObject.
      To prevent FreeFence() and FreeCounter() from segfaulting if the call to
      AddResource() fails before the sync object is initialized, this adds a new
      'initialized' parameter to SyncObject that, when FALSE, causes FreeFence() and
      FreeCounter() to skip de-initialization and simply free the object.
      Initialization after adding the resource shouldn't otherwise be a problem due to
      the single-threaded nature of X.
      Signed-off-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
      Reviewed-by: James Jones's avatarJames Jones <jajones@nvidia.com>
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
  6. 26 Sep, 2018 1 commit
  7. 02 Apr, 2018 1 commit
  8. 20 Sep, 2017 2 commits
  9. 26 Apr, 2017 1 commit
    • Eric Anholt's avatar
      Add a Meson build system alongside autotools. · 1549e303
      Eric Anholt authored
      This is a work in progress that builds Xvfb, Xephyr, Xwayland, Xnest,
      and Xdmx so far.  The outline of Xquartz/Xwin support is in tree, but
      hasn't been built yet.  The unit tests are also not done.
      The intent is to build this as a complete replacement for the
      autotools system, then eventually replace autotools.  meson is faster
      to generate the build, faster to run the bulid, shorter to write the
      build files in, and less error-prone than autotools.
      v2: Fix indentation nits, move version declaration to project(), use
          existing meson_options for version-config.h's vendor name/web.
      Signed-off-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Acked-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  10. 21 Mar, 2017 1 commit
  11. 08 Feb, 2017 1 commit
  12. 13 Dec, 2016 1 commit
    • Adam Jackson's avatar
      Revert "damage: Make damageRegionProcessPending take a damage not a drawable" · 32e632e8
      Adam Jackson authored
      The commit message makes the assertion that the code below damage is not
      allowed to change whether there's a damage monitor for the drawable.
      That turns out not to be the case! exa's mixed code, at least, will
      create and destroy a damage in PrepareAccess. The destroy path can then
      be catastrophic, as damageRegionProcessPending will attempt to
      RegionEmpty memory from the middle of a freed block.
      I'd wanted that invariant for performance, but faster isn't worth
      broken, so revert it. I think what exa's doing is reasonable, so the
      better way to improve performance for the unmonitored case is to either
      revisit dynamically wrapping into the GC, or inline damage into dix.
      This reverts commit 4e124203.
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1389886Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
  13. 12 Dec, 2016 4 commits
  14. 18 Jul, 2016 3 commits
  15. 20 Jun, 2016 1 commit
    • Keith Packard's avatar
      dix: Call screen block/wakeup handlers closest to blocking [v3] · fb1edccf
      Keith Packard authored
      The screen block and wakeup handlers are the only ones which provide a
      well known ordering between the wrapping layers; placing these as
      close as possible to the server blocking provides a way for the driver
      to control the flow of execution correctly.
      Switch the shadow code to run in the screen block handler so that it
      now occurrs just before the server goes to sleep.
      Switch glamor to call down to the driver after it has executed its own
      block handler piece, in case the driver needs to perform additional
      flushing work after glamor has called glFlush.
      These changes ensure that the following modules update the screen in
      the correct order:
      animated cursors        (uses RegisterBlockAndWakeupHandlers dynamically)
      composite               (dynamic wrapping)
      misprite                (dynamic wrapping)
      shadow                  (static wrapping)
      glamor                  (static wrapping)
      driver                  (static wrapping)
      It looks like there's still a bit of confusion between composite and
      misprite; if composite updates after misprite, then it's possible
      you'd exit the block handler chain with the cursor left hidden. To fix
      that, misprite should be wrapping during ScreenInit time and not
      unwrapping. And composite might as well join in that fun, just to make
      things consistent.
      [v2] Unwrap BlockHandler in shadowCloseScreen (ajax)
      [v3] ephyr: Use screen block handler for flushing changes
      ephyr needs to make sure it calls glXSwapBuffers after glamor finishes
      its rendering. As the screen block handler is now called last, we have
      to use that instead of a registered block/wakeup handler to make sure
      the GL rendering is done before we copy it to the front buffer.
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
  16. 18 May, 2016 1 commit
    • Adam Jackson's avatar
      damage: Make damageRegionProcessPending take a damage not a drawable · 4e124203
      Adam Jackson authored
      In the case where there's no damage monitor on the drawable, we look
      that fact up twice: once before rendering to decide whether to compute
      damage, and again after to decide whether to append it. This is wasted
      effort, as the layer below us is effectively not allowed to change
      whether there's a damage monitor for the drawable, but there's no way
      the compiler can know that.
      Instead, look it up once up front, and change the check macros and
      damageRegionProcessPending to take a damage not a drawable.
      v2: Explicitly pass pDamage to the macros as well (Michel Dänzer)
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
  17. 21 Sep, 2015 1 commit
    • Adam Jackson's avatar
      rootless: Fix bogus handling of broken root clip · fa0bb018
      Adam Jackson authored
      gcc quite correctly complains about this:
          In file included from ../../include/scrnintstr.h:51:0,
                           from rootlessValTree.c:98:
          In function 'RegionUninit.isra.1',
              inlined from 'RegionEmpty' at ../../include/regionstr.h:194:5,
              inlined from 'RootlessMiValidateTree' at rootlessValTree.c:490:9:
          ../../include/regionstr.h:166:9: warning: attempt to free a non-heap object 'RegionBrokenData' [-Wfree-nonheap-object]
      So that'd crash if you ever got there.  RegionNull will do almost the
      same thing only without the free(), so let's do that instead; it might
      still not be an entirely sane way to recover, but it at least won't
      Reviewed-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
  18. 18 Aug, 2015 2 commits
  19. 08 Jul, 2015 5 commits
  20. 21 Apr, 2015 1 commit
  21. 12 Nov, 2014 1 commit
  22. 08 Oct, 2014 1 commit
  23. 29 Jul, 2014 2 commits
    • Adam Jackson's avatar
      miext/shadow: Remove shadowInit · d5b27997
      Adam Jackson authored
      This code is nonsensical.  You end up creating a screen-sized pixmap
      that's totally detached from everything else, which you then listen for
      damage on, which means you'll never hear any damage, which means your
      shadow update hooks will never get called.  Any driver using this would
      be sorely disappointed.
      Reviewed-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
    • Adam Jackson's avatar
      miext/shadow: Remove ancient backwards-compatibility hack · cf4793d9
      Adam Jackson authored
      Here's a trip down memory lane.  Back when we merged kdrive we adopted
      kdrive's version of shadow, which used damage directly instead of
      hand-rolling it.  However a couple of Xorg drivers referred to the
      accumulated damage region in the shadow private directly, so I added a
      hack to copy the damage region around.
      That was 9148d870, back in early 2006.
      Eight years is unusually patient for me.  The neomagic and trident drivers
      were still relying on this, but they've been modified to ask the damage
      code for the region instead.
      Reviewed-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
  24. 17 Mar, 2014 1 commit
  25. 12 Jan, 2014 2 commits
  26. 02 Dec, 2013 2 commits