1. 01 May, 2019 5 commits
  2. 30 Apr, 2019 9 commits
  3. 29 Apr, 2019 1 commit
  4. 28 Apr, 2019 1 commit
  5. 23 Apr, 2019 1 commit
  6. 20 Apr, 2019 1 commit
  7. 18 Apr, 2019 5 commits
  8. 17 Apr, 2019 8 commits
    • 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>
    • Eric Anholt's avatar
      glamor: Introduce a central place for our pixmap format/type handling. · 8702c938
      Eric Anholt authored
      We had various helper functions trying to come up with the
      internalformat/format/type/render formats for pixmaps, and it's much
      nicer to just detect what those should be once at startup.  This gives
      us a chance to do the right thing for GLES.
      It also, notably, fixes our format/type for depth 15 and 16 setup for
      desktop GL, so that we actually allocate 16bpp (GL_RGB/565) on most
      drivers instead of 32bpp (GL_RGB/UBYTE).
      GLES still has regressions over desktop (2 regressions in llvmpipe
      XTS, many in rendercheck), but I think this is a good baseline.
      Signed-off-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
    • Eric Anholt's avatar
      glamor: Plumb the pixmap through fbo creation instead of a "format" · c94da112
      Eric Anholt authored
      For GLES, we're going to need a lot more logic for picking the
      iformat/format/type of texture setup, so we'll want the pixmap's depth
      and is_cbcr flag.
      Signed-off-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
    • Eric Anholt's avatar
      glamor: Stop trying to store the pixmap's "format" in glamor_pixmap_fbo. · 34485be2
      Eric Anholt authored
      "format" is a bit of a confused term (internalformat vs GL format),
      and all we really needed was "is this GL_RED?"
      Signed-off-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
    • Eric Anholt's avatar
      glamor: Switch the gl_flavor to a boolean is_gles. · 1b2e224d
      Eric Anholt authored
      There are only 2 flavors we are distinguishing -- GL versions are
      handled separately.
      Signed-off-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
    • Jon Turney's avatar
      Fix missing prototype warning for xf86_find_platform_device_by_devnum() · 2764128e
      Jon Turney authored
      ../hw/kdrive/src/kdrive.c:999:1: warning: no previous prototype for ‘xf86_find_platform_device_by_devnum’ [-Wmissing-prototypes]
      Place the same guards around this stub as are around including the
      hotplug.h header which declares the prototype.
    • Jon Turney's avatar
      Fix maybe-uninitialized warning in xf86NewInputDevice() · ba59427a
      Jon Turney authored
      If SYSTEMD_LOGIND is not defined, systemd_logind_take_fd is defined as a
      macro evaluating to -1 by systemd-logind.h, leaving paused
      ../hw/xfree86/common/xf86Xinput.c: In function ‘xf86NewInputDevice’:
      ../hw/xfree86/common/xf86Xinput.c:919:16: warning: ‘paused’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      ../hw/xfree86/common/xf86Xinput.c:877:10: note: ‘paused’ was declared here
    • Jon Turney's avatar
      Fix old-style definition warning for xf86OSInputThreadInit() · 7c266caf
      Jon Turney authored
      ../hw/xfree86/os-support/stub/stub_init.c: In function ‘xf86OSInputThreadInit’:
      ../hw/xfree86/os-support/stub/stub_init.c:29:1: warning: old-style function definition [-Wold-style-definition]
  9. 12 Apr, 2019 4 commits
    • Adam Jackson's avatar
      dix: Remove WindowRec::backStorage · 69758079
      Adam Jackson authored
      This is only being set, never read.
    • Adam Jackson's avatar
      dix, composite: Optimize setting window backing store state · 0f477cc6
      Adam Jackson authored
      We hide CWBackingStore from the screen hook if nothing's actually
      changing, which means compChangeWindowAttributes no longer needs to
      compare the requested state with the present one.
    • Adam Jackson's avatar
      mi: Simplify a conditional in miHandleExposures · 4e101e7e
      Adam Jackson authored
      miHandleExposures does two things: computes the region for which to
      generate expose events, and (if the destination is a window) paints the
      exposed regions with the background. The bit of this conditional we're
      deleting here asserts that the source is either a pixmap or a window
      without backing store. The only other possibility is a window _with_
      backing store. In the old backing store implementation, this was where
      you would recover bits from backing store. Since our "backing store" is
      the redirected window pixmap, we know we've already copied all we could,
      because CopyArea had already seen the entire window pixmap. So now in
      that third case, we are still drawing to a pixmap (so there's no
      background to paint) and we are still not generating events, so we can
      exit early.
      The comment above the function about recovering bits from backing store
      is clearly misleading, so delete that too.
    • Aaron Plattner's avatar
      xfree86: Export xf86GPUScreens and xf86NumGPUScreens · 147ed28b
      Aaron Plattner authored
      Drivers may need to loop over the allocated screens during PreInit, for example
      to consolidate xorg.conf options that apply to a GPU device as a whole.
      Currently, this works for protocol screens becuase x86Screens is exported, but
      does not work for GPU screens.
      Export xf86GPUScreens and xf86NumGPUScreens for consistency with xf86Screens and
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
  10. 04 Apr, 2019 1 commit
  11. 02 Apr, 2019 2 commits
  12. 01 Apr, 2019 2 commits