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.
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.
