1. 06 Jul, 2009 2 commits
  2. 16 Jun, 2009 1 commit
  3. 07 Apr, 2009 1 commit
  4. 06 Apr, 2009 2 commits
  5. 26 Mar, 2009 2 commits
  6. 18 Mar, 2009 1 commit
  7. 17 Mar, 2009 7 commits
  8. 13 Mar, 2009 1 commit
  9. 24 Feb, 2009 1 commit
  10. 21 Feb, 2009 1 commit
  11. 17 Feb, 2009 1 commit
  12. 02 Feb, 2009 3 commits
  13. 31 Jan, 2009 1 commit
  14. 29 Jan, 2009 2 commits
    • Paulo Cesar Pereira de Andrade's avatar
      patches to avoid gcc warnings for libX11 (#1) · 692baebc
      Paulo Cesar Pereira de Andrade authored
      Author is Peter Breitenlohner <peb@mppmu.mpg.de>
      Bug #17946, attachment #19439
      Define as 1 (one) as done by autoconf and the command line
      option, e.g. -DX11_t, not as empty.
      This avoids the gcc (3.4.6) warnings:
      	../../libX11-1.1.5/src/x11_trans.c:27:1: warning: "X11_t" redefined
      	<command line>:7:1: warning: this is the location of the previous definition
      	../../libX11-1.1.5/src/x11_trans.c:28:1: warning: "TRANS_CLIENT" redefined
      	<command line>:8:1: warning: this is the location of the previous definition
      Similarly, follow the autoconf convention to define XTHREADS
      and XUSE_MTSAFE_API as one.
      This avoids analogous warnings when compiling libXcomposite,
      libXcursor, and libXdamage.
      No reason to AC_SUBST XTHREADS and XUSE_MTSAFE_API (unused).
    • Paulo Cesar Pereira de Andrade's avatar
      Janitor: Correct some gcc/sparse warnings. · a1977883
      Paulo Cesar Pereira de Andrade authored
        Most remaining warnings are about XIM/Xim to/from conversion
      and discarding const from pointers.
  15. 28 Jan, 2009 1 commit
    • Paulo Cesar Pereira de Andrade's avatar
      Janitor: ansification, make distcheck, compiler warnings. · 8ba0ca32
      Paulo Cesar Pereira de Andrade authored
        Only convert to use "ansi prototypes" the functions warned from
      compilation with "./autogen.sh --prefix=/usr", on a Linux computer.
        Also, only address "trivial" compiler warning fixes in this commit.
        The new .gitignore is the output of a command like:
      % find . -name .gitignore -exec cat {} \; | sort | uniq
      and only the toplevel .gitignore file was kept.
  16. 13 Jan, 2009 1 commit
  17. 07 Dec, 2008 1 commit
  18. 22 Nov, 2008 1 commit
  19. 21 Nov, 2008 1 commit
  20. 18 Nov, 2008 1 commit
  21. 14 Nov, 2008 1 commit
  22. 05 Nov, 2008 1 commit
  23. 04 Nov, 2008 5 commits
    • Jamey Sharp's avatar
      Support multiple independent internal sync handlers · e6a7b70c
      Jamey Sharp authored
      Xlib has several independent tasks that need to be performed with the
      display unlocked. It does this by replacing the existing sync handler with
      one of a variety of internal sync handlers. However, if multiple internal
      sync handlers need to run, then the last one registering wins and
      previously registered internal sync handlers are never invoked. This
      manifested as a bug with DRI applications on Xlib/XCB as that requires
      both an XID handler after every XID allocation, and the periodic sequence
      number handler. The XID handler would win, and the sequence number handler
      would never be invoked.
      Fix this by unifying the internal sync handler mechanism into a single
      function that calls all of the known internal sync handlers. They all need
      to deal with being called when not strictly necessary now.
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Signed-off-by: Jamey Sharp's avatarJamey Sharp <jamey@minilop.net>
      Signed-off-by: Josh Triplett's avatarJosh Triplett <josh@freedesktop.org>
    • Keith Packard's avatar
      Ensure that _XReadEvents always leaves an event in the queue on return · 2dbaaab9
      Keith Packard authored
      XNextEvent assumes that the event queue will be non-empty on return from
      _XReadEvents, but with multiple event readers running, the previous change
      could leave the queue empty on return from process_responses. Re-invoke
      process_responses until the queue is non-empty.
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
    • Keith Packard's avatar
      Permit only one Xlib thread to block waiting for events · bedfe682
      Keith Packard authored
      As Xlib queues events internally, we must prevent multiple Xlib threads from
      entering XCB to wait for an event in case the queued event is to be
      delivered to the thread which didn't manage to read it. In other words, let
      only one Xlib thread into xcb_wait_for_event at a time.
      Jamey Sharp looked over my shoulder while making this fix and, while hating
      my whitespace conventions, appears happy enough with the actual code.
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
    • Jamey Sharp's avatar
      Fix XAllocID race: hold the user display lock until we have a new XID. · cc19618d
      Jamey Sharp authored
      Xlib built --without-xcb is also vulnerable to this race, and a similar
      fix might work there too.
      Also, use an XID that's truly invalid while waiting for the next XID to be
    • Josh Triplett's avatar
      Use XCB's new socket handoff mechanism rather than the old XCB Xlib lock. · 54e5c094
      Josh Triplett authored
      Previously, Xlib/XCB used XCB's Xlib lock to prevent XCB from sending
      requests between calls to Xlib's LockDisplay and UnlockDisplay macros.
      Xlib/XCB then sent all of its requests using XCB's xcb_send_request, and
      had to flush its requests when unlocking the display.
      XCB 1.2 adds a new socket handoff mechanism, xcb_take_socket.  Replace
      much of the existing Xlib/XCB implementation with the use of
      xcb_take_socket to take ownership of the write side of the X connection
      socket, and a return_socket callback which writes any outstanding requests
      with xcb_writev.  This approach allows Xlib/XCB to use the same buffering
      as traditional Xlib did.  In particular, programs which use Xlib/XCB and
      never make XCB calls will never need to hand the socket back to XCB, and
      vice versa.
      This allows us to discard large quantities of synchronization code from
      Xlib/XCB, together with the synchronization bugs present in that code.
      Several test cases which previously failed now work perfectly, including
      multi-threaded ico.  In addition, the infamous locking correctness
      assertions, triggered when double-locking or when unlocking without a
      previous lock, no longer exist, because Xlib/XCB no longer has any reason
      to care more about application locking than traditional Xlib does.
      Furthermore, the handoff approach provides great improvements to
      performance.  Results from x11perf's XNoOp test, which represented the
      worst case for the lock-based Xlib/XCB:
      Traditional Xlib:       average 19100000/sec
      Lock-based Xlib/XCB:    average  3350000/sec
      Handoff-based Xlib/XCB: average 17400000/sec
      Thus, for no-ops, the handoff mechanism provides more than a 4x speedup to
      Xlib/XCB, bringing Xlib/XCB within 9% of traditional Xlib no-op
      performance.  Of course, real-world workloads do not use no-op, so your
      mileage may vary.  In particular, since no-ops represent the worst case,
      we expect real workloads to more closely match the performance of
      traditional Xlib.
      While removing synchronization code, we changed _XReply to not drop any
      locks when calling xcb_wait_for_reply; previously, we had to carefully
      avoid a deadlock between the Display lock and the XCB Xlib lock. Holding
      the locks reduces implementation complexity and should not impact
      Commit by Jamey Sharp and Josh Triplett.
      XCB's handoff mechanism inspired by Keith Packard.
  24. 25 Oct, 2008 1 commit
    • James Cloos's avatar
      Increase size of working arrays in the makekeys utility program. · b1022fa6
      James Cloos authored
      Makekeys is used to create an optimal hash of the keysyms defined
      in x11proto’s keysymdef.h.
      The recent addition of new keysyms there has triggered a bug in
      makekeys where it tries to use a zero on the rhs of the % (mod)
      operator (resulting in a divide by zero error) whenever it fails
      to find a solution within its constraints.
      Increasing the size of the arrays allows it to find a solution for
      the current set of keysyms.
      Makekeys is only run durring the build process, so this has no impact
      on users of libX11, only on the amount of VM needed to build it.
      It still needs a more complete fix, but this allows compiles to
      progress until that is completed.