The code <U1000000D> was used where <U10000DC> was obviously intended.
It is possible that <Udiaeresis> should be used instead, if that will
not break anyone’s setup.
From bugzilla bug 10943¹:
There are several Catalan locale codes which presently can
be used in X11 systems; especially after they were accepted
in belocs-locale-data².
In the following patches, I³ add ca_AD, ca_FR and ca_IT Catalan
locale codes. For instance, without this, using ca_AD (actually
a quite used locale⁴) some applications (eg. Emacs or Skype)
cannot display Catalan diacritic marks as you type them.
1] https://bugs.freedesktop.org/show_bug.cgi?id=10943
2] http://lists.debian.org/debian-devel-changes/2005/07/msg01429.html
3] Toni Hermoso Pulido <toniher@softcatala.org>
4] https://launchpad.net/~ubuntu.cat/+members
The description from bugzilla bug 7417¹ is:
We've been shipping this patch for some time in Debian now. The
problem description from the patch header is reproduced below. You
may want to note the licensing issue mentioned below, but we've been
shipping it because the method by which this particular patch was
generated and updated was also given below.
This patch by Denis Barbier.
The X11 protocol states that Unicode keysyms are in the range
0x01000100 - 0x0110FFFF. If the result of composing characters is a
Unicode codepoint, X returns the corresponding Unicode keysym, which
is its Unicode codepoint augmented by 0x01000000. Latin-1
characters must not appear with their Unicode codepoints in compose
files, otherwise the returned composed character lies in the range
0x01000000 - 0x010000FF which is not valid.
There are two solutions: either fix composing routines to return
0xZZ instead of 0x010000ZZ (where Z is an hexadecimal digit), or
replace U00ZZ by their corresponding keysyms in compose files. The
latter is more logical and less error prone, so compose files will
be patched. Many applications accept these invalid Unicode keysyms,
but few of them don't, most notably xemacs. Only UTF-8 locales are
affected.
This has been fixed very recently in XFree86 CVS (but not xorg), but
for licensing reasons, this patch is not grabbed. Instead automatic
conversion is performed by:
sed -e '/XK_LATIN1/,/XK_LATIN1/!d' /usr/include/X11/keysymdef.h \
| grep -v deprecated | grep 0x0 \
| sed -e 's/0x0/U0/' -e 's/XK_//' \
| awk '{ printf "s/\\b%s\\b/%s/ig\n", $3, $2; }' > sedfile
for f in nls/*.UTF-8/Compose.pre
do
sed -f sedfile $f > $f.tmp && mv $f.tmp $f
done
[I edited the quoted script to update it for the current location of
the installed keysymdef.h and the current layout of the libX11
repo. -JimC]
I applied the script, not the patch attached to the bugreport.
1] https://bugs.freedesktop.org/show_bug.cgi?id=7417
I was told that some systems have a much more permissive libpthread.
I was asked to commit this. This is from NetBSD's X source.
(I didn't receive any feedback on xorg list for over two weeks
about this.)
Now that XFilterEvent drops the Display lock before invoking callback
functions, _XimGetWindowEventmask is called without the lock held. So
when it called _XGetWindowAttributes, a variant of XGetWindowAttributes
that does not lock the Display, Xlib/XCB would assert:
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Should fix Gentoo #156367, Ubuntu #87947, Debian #427296. And others?
Commit c337f9de7c broke the invariant that
_XReadEvents always enqueues at least one event even if an error occurred,
because the one call to xcb_wait_for_event would then return an error, not an
event, and nothing else ensured that process_responses would obtain an event.
Fix this by reverting most of c337f9de7c and
f417570735 and implementing the correct fix. In
process_responses, wait_for_first_event now serves as a flag, cleared when
actually handling an event.
Commit by Josh Triplett and Jamey Sharp.
This reverts commit c9e28e05ae.
The installed XlibInt.h includes XlibConf.h , so libX11 should ship
XlibConf.h. (Commit c9e28e05ae didn't actually
prevent automake from shipping XlibConf.h, because it used
nodist_x11include_HEADERS rather than nodist_HEADERS.)
We introduced this bug in 6b81cbbedf.
Also add a comment in _XCBUnlockDisplay to discourage this problem from
respawning.
Commit by Josh Triplett and Jamey Sharp.
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 $_;
}
}
