An Xlib client can query Display state, such as with NextRequest, while
it holds only the Xlib user lock (between XLockDisplay and
XUnlockDisplay), so XCB requests in other threads should be blocked when
the Xlib user lock is held.
We acquire the lock even when XInitThreads was not called, so that pure
XCB code can use multiple threads even in an otherwise single-threaded
Xlib application.
Commit by Josh Triplett and Jamey Sharp.
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.
Cf:
https://bugs.freedesktop.org/show_bug.cgi?id=10851https://bugs.freedesktop.org/show_bug.cgi?id=10824http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386385
The greek keyboard definition was changed to replace dead_horn and
dead_ogonek with U0313 COMBINING COMMA ABOVE (aka Psili) and U0314
COMBINING REVERSED COMMA ABOVE (aka Dasia).
This patch modifies the Greek Compose.pre to match.
It is generated by the script Jan Willem Stumpel <jstumpel@planet.nl>
posted to 386385@bugs.debian.org:
#!/usr/bin/perl
while (<>) {
print $_;
if (/dead_horn/) {
s/dead_horn/U0313/;
print $_;
}
elsif (/dead_ogonek/) {
s/dead_ogonek/U0314/;
print $_;
}
}
Man pages originally written for X11R6.4 integration to Solaris 7 11/99
Sun bug id 4258344: Add new XKB API manpages for 6.4 upgrade
<http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4258344>
(Volunteer needed to convert prototypes in man pages to ANSI C style...)
This fixes a bunch of cpp warnings from nls/en_US.UTF-8/Compose.pre.
Fixing that file would have been a larger diff, and using ## may be
nicer to use anyway.
Now only those fields of the respective hint struct are set that
are actually valid in the input data.
The changed functions are:
XSetSizeHints(), XSetWMHints() and XSetWMSizeHints().
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.
