The code is wrong since the first git revision, so it seens that it has
not been compiled with WORD64 for quite some time, there is also another
interesting code in xkb/XKBRdBuf.c:
<hash>ifdef WORD64
_XkbWriteCopyData32 Not Implemented Yet for sizeof(int)==8
<hash>endif
and possibly there are other similar problems.
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.
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 <keithp@keithp.com>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Josh Triplett <josh@freedesktop.org>
I refuse to take any responsibily for this code. It works, I guess.
But - all the flushing is done somewhere before that, so we might need to
flush here. Under some circumstances anyway. Don't ask me, I'm an optical
illusion.
Build with xcb as transport layer highly recommended.
If given many requests without replies, Xlib may not sync until it flushes
the output buffer. Thus, if Xlib can fit enough requests in the buffer to
pass by the number of requests it would normally sync after (65536 -
BUFSIZE/sizeof(xReq)), it will sync too late. The test case in bug 15023
demonstrated this by issuing a request with a reply (ListExtensions) at
just the right time to get confused with the GetInputFocus reply issued in
response to the sync 65,536 requests later; the test case used an async
handler to watch the replies, since otherwise it could not issue a request
without waiting for the response. When the test case failed, Xlib's sync
handler would eat the ListExtensions reply, and the test case's async
handler would see the GetInputFocus reply.
Fix this by replacing SEQLIMIT with a function sync_hazard() that uses the
buffer size to figure out when the sequence numbers could potentially wrap
before the next flush.
With this commit, the test case consistently passed, and the async reply
handler always saw the ListExtensions reply.
Commit by Jamey Sharp and Josh Triplett.
Some libraries try to clean up X resources from atexit handlers, _fini,
or C++ destructors. To make these work, the Display lock should be
downgraded to a user lock (as in XLockDisplay) before calling exit(3).
This blocks Xlib calls from threads other than the one calling exit(3)
while still allowing the exit handlers to call Xlib.
This assumes that the thread calling exit will call any atexit handlers.
If this does not hold, then an alternate solution would involve
registering an atexit handler to take over the lock, which would only
assume that the same thread calls all the atexit handlers.
Commit by Josh Triplett and Jamey Sharp.
- For Xcomposite and Xdamage, don't link the build system out of the xc tree
- Link the public X11 headers into their own directory
- Add links to XKeysymDB and XErrorDB
- Add links to all the Xlib man pages
- Add links to the lcUniConv subdirectory
- Conditionally include config.h in Xlib source
