1. 27 Mar, 2014 1 commit
  2. 10 Jul, 2012 8 commits
  3. 18 Apr, 2012 1 commit
    • Erkki Seppälä's avatar
      Xext: add a generic hashtable implementation · ccb3e781
      Erkki Seppälä authored
      The generic hashtable implementation adds a key-value container, that
      keeps the key and value inside the hashtable structure and manages
      their memory by itself. This data structure is best suited for
      fixed-length keys and values.
      One creates a new hash table with ht_create and disposes it with
      ht_destroy. ht_create accepts the key and value sizes (in bytes) in
      addition to the hashing and comparison functions to use. When adding
      keys with ht_add, they will be copied into the hash and a pointer to
      the value will be returned: data may be put into this structure (or if
      the hash table is to be used as a set, one can just not put anything
      The hash table comes also with one generic hashing function plus a
      comparison function to facilitate ease of use. It also has a custom
      hashing and comparison functions for hashing resource IDs with
      Reviewed-by: default avatarRami Ylimäki <rami.ylimaki@vincit.fi>
      Signed-off-by: default avatarErkki Seppälä <erkki.seppala@vincit.fi>
  4. 01 Mar, 2011 1 commit
  5. 07 Dec, 2010 1 commit
    • James Jones's avatar
      Create/Destroy/Trigger/Reset/Query Fence Sync objs · 397dfd9f
      James Jones authored
      Initial server side implementation of fence sync
      objects.  Allows creation, management, and state
      queries of binary state objects.  Currently they
      are not very useful as there is no way to wait for
      them efficiently.
      The basic trigger operation added here triggers
      relative to a given X screen's rendering operations.
      To perform this operation, fence sync objects must
      be tied to a screen.  As Aaron Plattner pointed out,
      screens are identified but a drawable in X protocol,
      so a drawable argument is included in
      XSyncCreateFence().  The screen also could have been
      specified as part of the trigger operation.  However,
      it is also desireable to associate a screen with
      fence sync objects at creation time so that the
      associated screen's driver can allocate any HW-
      specific resources needed by the fence object up
      Signed-off-by: default avatarJames Jones <jajones@nvidia.com>
      Reviewed-by: default avatarKeith Packard <keithp@keithp.com>
  6. 03 Jun, 2010 1 commit
  7. 21 Apr, 2010 1 commit
  8. 22 Mar, 2010 1 commit
    • Yaakov Selkowitz's avatar
      New header for XF86Bigfont server functions · abf4e0b7
      Yaakov Selkowitz authored
      Xext/xf86bigfont.c contains three non-static functions which are called
      elsewhere in the server.  This creates a new header containing these
      declarations in order to fix several warnings:
      xf86bigfont.c:285: warning: no previous prototype for `XF86BigfontFreeFontShm'
      dixfonts.c:502: warning: implicit declaration of function `XF86BigfontFreeFontS$
      dixfonts.c:502: warning: nested extern declaration of `XF86BigfontFreeFontShm'
      log.c:436: warning: implicit declaration of function `XF86BigfontCleanup'
      log.c:436: warning: nested extern declaration of `XF86BigfontCleanup'
      Signed-off-by: default avatarYaakov Selkowitz <yselkowitz@users.sourceforge.net>
      Reviewed-by: Julien Cristau's avatarJulien Cristau <jcristau@debian.org>
  9. 12 Mar, 2010 1 commit
  10. 14 Oct, 2009 1 commit
  11. 04 Apr, 2009 2 commits
  12. 18 Dec, 2008 1 commit
  13. 11 Dec, 2008 1 commit
  14. 03 Dec, 2008 1 commit
    • Paulo Cesar Pereira de Andrade's avatar
      Rework symbol visibility for easier maintenance · 49f77fff
      Paulo Cesar Pereira de Andrade authored
        Save in a few special cases, _X_EXPORT should not be used in C source
      files. Instead, it should be used in headers, and the proper C source
      include that header. Some special cases are symbols that need to be
      shared between modules, but not expected to be used by external drivers,
      and symbols that are accessible via LoaderSymbol/dlopen.
        This patch also adds conditionally some new sdk header files, depending
      on extensions enabled. These files were added to match pattern for
      other extensions/modules, that is, have the headers "deciding" symbol
      visibility in the sdk. These headers are:
      o Xext/panoramiXsrv.h, Xext/panoramiX.h
      o fbpict.h (unconditionally)
      o vidmodeproc.h
      o mioverlay.h (unconditionally, used only by xaa)
      o xfixes.h (unconditionally, symbols required by dri2)
        LoaderSymbol and similar functions now don't have different prototypes,
      in loaderProcs.h and xf86Module.h, so that both headers can be included,
      without the need of defining IN_LOADER.
        xf86NewInputDevice() device prototype readded to xf86Xinput.h, but
      not exported (and with a comment about it).
  15. 04 Nov, 2008 1 commit
  16. 31 Jul, 2008 1 commit
    • Aaron Plattner's avatar
      Make shmint.h part of the SDK. · b37b1e66
      Aaron Plattner authored
      This includes ShmRegisterFuncs, ShmSetPixmapFormat, fbShmPutImage, and
      ShmRegisterFbFuncs.  Note that fbShmPutImage was already exported.
  17. 24 Jul, 2008 4 commits
  18. 18 Jul, 2008 1 commit
  19. 12 May, 2008 1 commit
  20. 18 Apr, 2008 4 commits
  21. 26 Jan, 2008 1 commit
  22. 08 Nov, 2007 1 commit
  23. 17 Oct, 2007 1 commit
  24. 03 Oct, 2007 1 commit
  25. 04 Sep, 2007 1 commit
  26. 10 Jul, 2007 1 commit