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>
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 <keithp@keithp.com>
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 <keithp@keithp.com>
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
requested.
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
applications.
Commit by Jamey Sharp and Josh Triplett.
XCB's handoff mechanism inspired by Keith Packard.
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.
makekeys needs to be run during the build process, as opposed to on the
target, so build it with either of gcc or cc to fix cross-compiling.
This can be overridden by setting $CC_FOR_BUILD.
The <dead_acute> <C> and <dead_acute> <c> lines in the pt_BR UTF-8
Compose file show "Ç" and "ç" (c with cedilla accent) (akin to the
ISO 8859 pt_BR Compose file) as the string but specify the keysym
and comment for Ć and ć (c with acute accent).
This commit normalizes those two lines to match the specified string.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=4671
Signed-off-by: James Cloos <cloos@jhcloos.com>
Unicode 1.1 added thirds, fifths, sixths and eights;
we might as well catch up.
(Unicode and ISO 10646 have 1/7 (U2150), 1/9 (U2151), 1/10 (U2152)
and 0/3 (U2189) in their pipelines, but those four can be added
here after they are published.)
As reported in <https://bugs.freedesktop.org/show_bug.cgi?id=17228>:
Commit a6f4bbf7
nls (en_US): remove long compositions that override shorter [...]
removed some longer compose sequences because there are shorter
ones which take preference over the longer. For example the
sequences:
<Multi_key> <apostrophe> <comma> <c> : U1E09 # ḉ
<Multi_key> <apostrophe> <comma> <C> : U1E08 # Ḉ
were removed becase there already was:
<Multi_key> <apostrophe> <comma> : U201A # ‚
Then commit 4ba09125
Work on making the en_US and pt_BR UTF-8 Compose as similar as
possible added exactly the same key sequences again. Obviusly
they won't work.
The last commit missed the el_GR UTF-8 Compose.pre as well as
the various ISO 8859 locales which have compose sequences
generating ‘WITH CEDILLA’ characters.
(Interestingly, some of the 8859 locales already supported
<Multi_key> <cedilla> for some CEDILLA characters, but not
for Ç or ç.)
This is further work on bug 10397.
The en_US and pt_BR UTF-8 Compose tables had support for using <comma>
with <Multi_key> to enter CEDILLA characters. Bug 10397 requests
support for using <cedilla> instead of <comma> in said sequences.
This commit makes both styles work.
For network transports, there's enough delay in the network layer
already without adding more. For local transports, just hurry up
and fail if the server isn't there.
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.
Commit 6b6caeea83 added <dead_belowdot>
<A> and <dead_belowdot> <a> compose sequences for letters U+1E00 and
U+U1E01 (LATIN CAPITAL/SMALL LETTER A WITH RING BELOW). This caused
duplicate compose sequences since these have already been defined. Also,
using <dead_belowring> is more logical since the diacritic is indeed
a "RING BELOW".
No-one uses 8859-5 anymore, so make the default for Russian UTF-8; the
only other possible answer would be KOI8-R.
Signed-off-by: Sergey V. Udaltsov <sergey.udaltsov@gmail.com>
When looking at Thai input methods, make sure XMODIFIERS is checked
before jumping straight into built-in Thai processing, so external XIM
servers such as SCIM can be used with Thai.
