Commit 554f755e55 added generic event
cookie handling. Bump libX11 version number accordingly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
utlist.h contains the linked list macros, it was added with the recent
addition of event cookies but utlist.h wasn't added to the Makefile.am. As a
result, make dist failed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Generic events require more bytes than Xlib provides in the standard XEvent.
Memory allocated by the extension and stored as pointers inside the event is
prone to leak by simple 'while (1) { XNextEvent(...); }' loops.
This patch adds cookie handling for generic events. Extensions may register
a cookie handler in addition to the normal event vectors. If an extension
has registered a cookie handler, _all_ generic events for this extensions
must be handled through cookies. Otherwise, the default event handler is
used.
The cookie handler must return an XGenericEventCookie with a pointer to the
data.The rest of the event (type, serialNumber, etc.) are to be filled as
normal. When a client retrieves such a cookie event, the data is stored in
an internal queue (the 'cookiejar'). This data is freed on the next call to
XNextEvent().
New extension interfaces:
XESetWireToEventCookie(display, extension_number, cookie_handler)
Where cookie_handler must set cookie->data. The data pointer is of arbitray
size and type but must be a single memory block. This memory block
represents the actual extension's event.
New client interfaces:
XGetEventData(display, *cookie);
XFreeEventData(display, *cookie);
If the client needs the actual event data, it must call XGetEventData() with
the cookie. This returns the data pointer (and removes it from the cookie
jar) and the client is then responsible for freeing the event with
XFreeEventData(). It is safe to call either function with a non-cookie
event. Events unclaimed or not handled by the XGetEventData() are cleaned up
automatically.
Example client code:
XEvent event;
XGenericEventCookie *cookie = &ev;
XNextEvent(display, &event);
if (XGetEventData(display, cookie)) {
XIEvent *xievent = cookie->data;
...
} else if (cookie->type == GenericEvent) {
/* handle generic event */
} else {
/* handle extension/core event */
}
XFreeEventData(display, cookie);
Cookies are not multi-threading safe. Clients that use XGetEventData() must
lock between XNextEvent and XGetEventData to avoid other threads freeing
cookies.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
GenericEvent cannot be selected for in the core event masks and they must
thus be treated like extension events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
GenericEvents have no fixed position for the window, so they must be treated
like extension events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The replaces the instances of keysyms which match <U03[0-6][0-9A-Fa-f]>,
where the keysym is used as a dead_key, with an actual dead_key symbol.
The only remaining instances of UCS combining characters in the
compose sequences are of U0338 COMBINING LONG SOLIDUS OVERLAY
used as a suffix in Multi_key-initiated sequences to create
mathematics characters such as ∉ U+2209 NOT AN ELEMENT OF
from ∈ U+2208 ELEMENT OF.
This removes those instances of keysyms which match <U03[0-6][0-9A-Fa-f]>,
where the matching keysym is used as a dead_key, and for which alternative
compose sequences exist.
Some of the UTF-8 Compose tables included combining_ keysyms in
the compose sequences as though they were dead symbols. This
is contrary to how combining characters are used in the UCS.
Therefore, those lines have been removed from the Compose tables.
There were also some combining_ keysyms as targets. As those
are not included in x11proto’s keysymdef.h, and as those do
exist there as Uxxxx keysyms, they are replaced with the Uxxxx
keysym names.
This addresses http://bugzilla.freedesktop.org/show_bug.cgi?id=5107
and is based on attachment 25644 by samuel.thibault@ens-lyon.org.
Signed-off-by: James Cloos <cloos@jhcloos.com>
Commit 97fc6babd4 "NLS: Add UTF-8 compose
file for Finnish" made fi_FI.UTF-8 use a broken empty XLC_LOCALE file.
This reverts it back to using the en_US.UTF-8 one.
On th_TH.UTF-8 locale, Thai XIM rejects all combining characters for GTK+ apps
that use X Input Method.
This is because GTK+ imxim immodule passes surrounding text in locale encoding,
which is UTF-8 for UTF-8 locales. But current Thai XIM in Xlib assumes the
multi-byte StringConversionText response for the StringConversionCallback to
always be TIS-620, by retrieving a single byte and using it as-is.
If the Thai XIM tries to convert the multi-byte text based on locale codeset
before using it, it will work again.
X.Org But 12759 <http://bugs.freedesktop.org/show_bug.cgi?id=12759>
Signed-off-by: Theppitak Karoonboonyanan <thep@linux.thai.net>
Signed-off-by: Julien Cristau <jcristau@debian.org>
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>
