Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

X11 keyboard handling for 1.3 - WIP & call for help #82

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

X11 keyboard handling for 1.3 - WIP & call for help #82

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments


Copy link

@SDLBugzilla SDLBugzilla commented Feb 10, 2021

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 2.0
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2007-12-20 12:35:24 +0000, Christian Walther wrote:

Some time ago, I set out to implement the new SDL 1.3 keyboard API for X11, based on my previous work in this area (Bug 319). At some point I got stuck on a problem that I could not find a satisfactory solution for. In the hope that someone else can help me out, here is a patch that contains what I arrived at.

In its present state, the code mostly works with the western keyboard layouts I have tested, but most likely fails miserably as soon as input methods are involved. Specifically, GetLayoutKey() turned out to be less straightforward to implement than I had hoped. What I need there, for character keys, is basically a static mapping from X11 KeySyms to one-character (unicode) key names (static because KeySyms correspond 1:1 to our concept of a "layout key code"). But I have been unable to find an elegant way of doing this. Xutf8LookupString(), which I'm using now, is inappropriate because it takes into account dead keys and input methods (and probably messes up the XIC that I'm currently borrowing from the first window). XLookupString() works, but only for Latin-1 characters. XKeysymToString() produces ASCII strings, not single characters. The only correct way I can imagine is to have a giant look-up table containing all thousands of KeySyms. I'm hoping some X11 expert (which I am not) has a better idea here... or perhaps the API we designed is just unimplementable and needs to be revised.

Other unfinished or questionable points:

  • I haven't implemented generation of text events because I don't understand what's going on in the commented-out SDL 1.2 code with saved_keysym.
  • I've resurrected the X11_KeyRepeat() function from SDL 1.2. Was there a particular reason why it was removed?
  • Due to what I wrote in, I can't use SDL_iconv() for UTF-8/SDLKey conversions (it's probably a bit heavy-weight anyway). Instead I've taken fragments of the integrated SDL_iconv() implementation and put them into the functions encodeUtf8() in SDL_keyboard.c and decodeUtf8() in SDL_x11keyboard.c. This should probably be centralized somewhere.

On 2007-12-20 12:36:31 +0000, Christian Walther wrote:

Created attachment 238
Patch against r3452

On 2007-12-29 14:04:00 +0000, Sam Lantinga wrote:

Christian, can you get in touch with Bob to help address your main point with input methods?

Key repeat is now defined as handled by the OS, since the SDL implementation worked by saving the last key down event and re-sending it at specified intervals, which doesn't make sense in SDL 1.3.

On 2007-12-30 08:23:34 +0000, Christian Walther wrote:

Created attachment 242
New patch against r3501

On 2007-12-30 08:27:26 +0000, Christian Walther wrote:

Thanks to Bob Pendleton who pointed me to "imKStoUCS", I found out that:

  • we're not the first ones to have this problem, and
  • everyone has solved it using the "giant look-up table" approach.

I have found two basic varieties of such tables out in the wild:

They have 819 entries in common, 377 are in the former only, 46 in the latter only, and 84 conflict. Unable to judge the quality of the mappings (particularly with respect to the conflicting entries, most of which appear in the Korean range (0x0Exx)), I decided to go with the numbers and choose the former. In the hope that this helps avoid a mess, I integrated that file as-is, except for the addition of the license header (which lives in a central file in the source) and modification of #include statements.

So, here is an updated patch that should now work properly in all cases (after some minor tweaking, I expect). Bob, what do you think about this?

Some of the caveats mentioned above still stand:

  • No text inputs are generated yet.
  • encodeUtf8() still needs to be reconciled with SDL_iconv() (but decodeUtf8() is gone).

On 2009-02-16 20:53:07 +0000, Sam Lantinga wrote:

I think this is resolved in the current SDL 1.3 code. Christian, can you confirm?

On 2009-02-22 12:17:33 +0000, Christian Walther wrote:

I haven't followed SDL development for a while (as you may have noticed), but from a cursory glance at the current source, it looks like it. imKStoUCS.c, which was the solution for the original problem, is still used.

@SDLBugzilla SDLBugzilla added the enhancement label Feb 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

1 participant