X11: unicode, XKB

Hello.

Will a patch to use XKB instead of basic Xlib for keyboard input be
accepted?

It was spawned in desperate attempts to get Unicode working for switched
keyboard layout. As it turned out, SDL-1.2.5 on my system (stock rh8.0,
bundled X11) ignored group switches between US and Cyrillic.

After a while I gave up trying to fix it with core Xlib calls and
partially-implemented XKB support instead. If the patch will be welcome,
I’ll clean up the code and post it.–

./lxnt

Hello.

Will a patch to use XKB instead of basic Xlib for keyboard input be
accepted?

It was spawned in desperate attempts to get Unicode working for switched
keyboard layout. As it turned out, SDL-1.2.5 on my system (stock rh8.0,
bundled X11) ignored group switches between US and Cyrillic.

After a while I gave up trying to fix it with core Xlib calls and
partially-implemented XKB support instead. If the patch will be welcome,
I’ll clean up the code and post it.

Sure. Does the XInput extension do the job though?

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Sam Lantinga wrote:

Sure.

That’s good. Working on it.

Does the XInput extension do the job though?

Are you talking of Xinput or X Input Method (XIM) (code comments suggest
later)?

As far as I understand the Xinput docs, it just reimplements the core
Xlib calls what have something to do with keycode-to-keysym translation
with the same semantics (only adding device id of some kind). This is
known not to work with my setup. Core Xlib protocol is not aware of the
group notion and therefore core functions, such as XKeycodeToKeysym and
XLookupString are unable to take current group into account. Maybe
client library XKB part is intended to somehow synthesize MappingNotify
event or do something to make XKeycodeToKeysym and friends aware of
changed keycode->keysym mapping, but this is obviously not done now.

Of XIM I feel that it needs too much of a context for it to be used in
SDL. It also is focused on input methods, as in “means to input text
(really any text)”, while I feel that SDL is more concerned with
lower-level keyboard input, unicode support being somewhat secondary,
though quite helpful, feature. Besides I doubt that input methods exist
anywhere beyound more-or-less powerful machines running X11 or
Windows (and god only knows how do they work in DirectX, if at all).

Of Unicode support in general it came to me as a small surprise that
nowadays Unicode character may be as wide as 3 bytes, characters being
defined up to U+10FFFF (i.e. 0x0010ffff). (i.e. that would be 4 bytes in
UTF-8 encoding). Thus imho we should either consider expanding
SDL_keysym::unicode to Uint32 or explicitly state that we don’t support
anything over 16 bits ( what there is can be seen at
http://www.unicode.org/charts/ (look at the linked PDF names) ).–

./lxnt

Hello.

Here’s current version of the patch.

http://lxnt.info/sdl/xkb.diff

It is to be considered work-in-progress.

However, I could use some help in testing it and your opinions.

Short description:

  • configure option --disable-video-x11-XKB can be used to turn off
    configure-time XKB detection (needs better name?)

  • If XKB extension is available at the server, X11 KeyCode to KeySym
    translation is handled by XKB code.

  • XKB key repeat detection is used if available.

  • Unicode support is rewritten to use X11 KeySym to UCS translation instead of
    XLookupString. Conversion function taken from Xterm UTF8 fork or something:
    http://www.cl.cam.ac.uk/~mgk25/ucs/keysym2ucs.c
    http://www.cl.cam.ac.uk/~mgk25/ucs/keysym2ucs.h

Supported are:

U+01xx Latin
U+03xx Greek
U+04xx Cyrillic
U+05xx Hebrew
U+06xx Arabic
U+oExx Thai
U+30xx Katakana (japanese)
U+31xx Hangul (korean)

Plus a bunch of symbols from other pages.–

./lxnt