The Thai XIM component in libx11 activated on 'th*' locales normally filters
input sequence according to orthographic rules. However, when NumLock/CapsLock
is on, this stops working. All sequences are passed through.
This is caused by missing masks in _XimThaiFilter(), which normally screens out
certain special keys from entering orthographic rules. Unfortunately, this
included events with NumLock/CapsLock on. Negating the masks from the check
allows the events to be tested by the rules.
X.Org Bug 12517 <http://bugs.freedesktop.org/show_bug.cgi?id=12517>
Signed-off-by: Theppitak Karoonboonyanan <thep@linux.thai.net>
Signed-off-by: Julien Cristau <jcristau@debian.org>
SCIM fails to commit Thai input characters on Thai locales, because it commits
string in compound text form, which was converted via
XwcTextListToTextProperty(). But the XLC_LOCALE for th_TH and th_TH.UTF-8
declares cs1's ct_encoding as TIS620-0:GR, which was commented out in
src/xlibi18n/lcCT.c default_ct_data, in favor of ISO8859-11 ESC sequence.
So, declaring cs1 as ISO8859-11:GR instead makes it work.
Besides, for th_TH.UTF-8, adding cs2 class with ISO10646-1 encoding also adds
support for UTF-8 input.
And, along discussion in the bug, a similar problem was found for fontset, too,
by causing delays on X apps startups on systems without tis620-0 fonts. This
is normally the case, as mkfontdir and mkfontscale generate iso8859-11 entries
by default for Thai X fonts. So, Thai fontset charset is also patched.
X.Org Bug 16475 <http://bugs.freedesktop.org/show_bug.cgi?id=16475>
Signed-off-by: Theppitak Karoonboonyanan <thep@linux.thai.net>
Signed-off-by: Julien Cristau <jcristau@debian.org>
This reverts commit 892b401d5a.
As Julien Cristau correctly points out, I misread the Compose file grammar
in modules/im/ximcp/imLcPrs.c, and those are keysyms, not comments, and
the keysym is named XK_masculine in keysymdef.h. This change is thus a
bug in the Solaris compose tables to be fixed, not an improvement to bring
upstream.
Matches the ordfeminine name used for the matching character,
and the ordmasculine name used in many font descriptions of the glyph.
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
This copy of Xrm.c is never compiled into the Xprint server any more, so
this old code-sharing #ifdef from the monolith tree isn't needed.
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
fi_FI was setting "x11thislocaledir" to en_US, with the result that its
locale data was written in that locale dir.
Signed-off-by: Chris Ball <cjb@laptop.org>
Since the Xlib multithreaded code checks the flags variable in _XFlushInt
to see if the other threads are done yet, it has to be marked volatile so
the compiler doesn't optimize out re-loading it on each trip through the
while loop and end up in an impossible-to-exit infinite loop of CPU chewing.
Part of fix for Sun bug 6409332: infinite loop in XFlushInt() on x86/32-bit
<http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6409332>
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Oops, cccp aliased cc for question mark. Upper-case it to avoid fail.
Signed-off-by: Will Thompson <will@willthompson.co.uk>
Signed-off-by: Daniel Stone <daniel@fooishbar.org> (sorry)
Note that a full review was not done, only for functions that receive
char/short arguments, or one of it's parameters is a function pointer
that requires char/short arguments.
The code is wrong since the first git revision, so it seens that it has
not been compiled with WORD64 for quite some time, there is also another
interesting code in xkb/XKBRdBuf.c:
<hash>ifdef WORD64
_XkbWriteCopyData32 Not Implemented Yet for sizeof(int)==8
<hash>endif
and possibly there are other similar problems.
An uninitialized or otherwise invalid condition variable can apparently
cause a hang in pthread_cond_broadcast. Ekiga, openoffice, and xine
at least are freezing as a result of event_notify never being initialized.
Signed-off-by: Brian Rogers <brian@xyzw.org>
Signed-off-by: Bart Massey <bart@cs.pdx.edu>
