This man page does not discuss the actual return values of the
function, but says they are of type "Status". One might assume
that this means you could compare it with the "Success" macro.
One would be wrong.
The X functions seem to have two three types representing status.
If it is an "int" there are a number of error codes or "Success"
which can be compared against. If it is a bool, the result can be
compared with "True" or "False". If the return type is "Status" it
appears that the return type is either 0 or 1. Unfortunately the
value for Success is zero, so it is important to distinguish
between the first two types of return values and the third;
otherwise the conditional will be inverted.
XGetWindowAttributes() is one of the functions which returns zero
for failure. The man page should make this clear.
Previously, process_responses (in the wait_for_first_event case called
from _XReadEvents) considered any return from xcb_wait_for_event
sufficient to think it had processed an event. If xcb_wait_for_event
returned an error, and no more events occurred before process_responses
called xcb_poll_for_event, process_responses would try to return with
dpy->head NULL, and would fail an assertion for the _XReadEvents
postcondition. Now, process_responses continues using xcb_wait_for_event
until it gets an event.
The fix for bug #8622 introduced a smaller bug where _XReply would
read memory shortly after freeing it. This patch caches the needed
value in a stack-allocated variable before the heap-allocated memory
is freed.
_XReply drops the Display lock, so the value of dpy->request may change
before _XReply is called again.
I discovered this by inspection a year or two ago. I'm pretty confident
in the claim, and nobody has come up with an argument for why it's safe
despite appearances.
Previously, process_responses (the common code for _XReply,
_XReadEvents, and _XEventsQueued) took the current request sequence
number as an argument, and did some highly complicated processing to
attempt to process responses in order across threads. This didn't
actually work.
Now, process_responses handles responses in order, by adding condition
variables to the list of outstanding requests in
dpy->xcb->pending_requests, and blocking on them when those requests
should get processed to allow _XReply to process them; if actually
called from _XReply, it returns when _XReply's request should get
processed. _XReply broadcasts on the condition variable after it has
read its reply and re-acquired the display lock.
Another great commit brought to you by Jamey Sharp, Josh Triplett, the
Gobby collaborative text editor, conspy, and ridiculous amounts of SSH
forwarding.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Remove long compositions that override (or get overriden by) later shorter
compositions, e.g. a four-key compose sequence that gets overriden by a
later three-key compose sequence.
Some XKB functions didn't correctly call LockDisplay or UnlockDisplay.
This patch fixes at least some instances of that problem.
Thanks to Magnus Kessler <Magnus.Kessler@gmx.net> for finding these bugs
and proposing a fix, which this patch is based on.
Rename all instances of "XCL" to Xlib/XCB-derived names.
The only user-visible change: rename the include file <X11/xcl.h> to
<X11/Xlib-xcb.h>; programs will need to change their #include lines to match.
Remove the XCL cast inlines from Xlib-xcb.h.
We can never change the libX11 soname, and we don't want to commit to never
changing the public Xlib/XCB functions, so split them into a separate library
libX11-xcb. This also means that a program linked solely against libX11
should work with either Xlib or Xlib/XCB, which will make life easier for
package maintainers.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Acked-by: Jamey Sharp <jamey@minilop.net>
No more recursive mutexes, no more banging XCB's I/O lock in-place, and
reduces the differences between the previous stable release and an
XCB-enabled one. Sadly, Xlib's pluggable thread functions work again
too, now. I apologize to the world.
Port to X11R7 of Sun bug fix 4061225 by Alex Chen for X11R6 - when failing to
connect on a named pipe, try a Unix socket first, to better support people who
replace their X servers with ones that don't support named pipe transport.
<http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4061225>
