[PATCH] Fix input keys in non-English locale in Linux

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Post Reply
Message
Author
zhur
Space Floater
Posts: 38
Joined: Thu Aug 09, 2012 8:15 am

[PATCH] Fix input keys in non-English locale in Linux

#1 Post by zhur »

Hello. I figured out a small fix/workaround for inability to input keys in non-English layout in Linux. I don't know if it is the correct one so here are my observations:
* The problem lies in OISInput::keyPressed getting an OIS::KeyEvent event with event.key field OIS::KC_UNASSIGNED in case of a non-English locale (event.text is meaningful in this case though).
* It then passed to GGKeyFromOISKey which returns a Key key equal to GGK_UNKNOWN.
* HandleGGEvent is not called in this case after failing test that key isn't GGK_UNKNOWN.

The patch (GPLv2 or later) adds a second check - event.text should be zero as well to ignore this key press/release. This way I can type Russian text into variuos GUI elements ingame.
Attachments

[The extension patch has been deactivated and can no longer be displayed.]


User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: [PATCH] Fix input keys in non-English locale in Linux

#2 Post by Geoff the Medio »

That sounds like it will fix the typing issue with non-US keyboard layouts, which is good.

But it also sound like there will be no way to use any hotkeys in Linux when using a non-US keyboard layout, since all keypress events are returning GGK_UNKNOWN, and hotkeys are based on the key press enum, not the event text field. If you could figure out why that's happening, it'd be better.

zhur
Space Floater
Posts: 38
Joined: Thu Aug 09, 2012 8:15 am

Re: [PATCH] Fix input keys in non-English locale in Linux

#3 Post by zhur »

Geoff the Medio wrote:That sounds like it will fix the typing issue with non-US keyboard layouts, which is good.
I think it still needs at least some testing especially on Windows.
Geoff the Medio wrote:But it also sound like there will be no way to use any hotkeys in Linux when using a non-US keyboard layout, since all keypress events are returning GGK_UNKNOWN, and hotkeys are based on the key press enum, not the event text field. If you could figure out why that's happening, it'd be better.
Exploring a little bit more it seems like this isn't possible without modification of OIS:
* When LinuxKeyboard::capture is called it stores a keycode in event.xkey.keycode
* But when LinuxKeyboard::_injectKeyDown is called later it is only passed a KeySym key and UTF32 character
* LinuxKeyboard::_injectKeyDown finds a correspondence of X11 KeySym to OIS KeyCode and calls OISInput::keyPressed with a found corresponding KeyCode kc (KC_UNASSIGNED for non-English KeySyms)

That means that keycode (and even KeySym) is actually lost inside of libOIS and I have no idea how to get it back. Maybe to we can have a reverse mapping of UTF32 character into a GG Key? But that sounds too hack-ish.

I just tried Wesnoth (AFAIK also using OIS but CeGUI instead of GG) and they don't handle standard hotkeys when I am using Russian layout. Funny thing is that if I set some hotkey to a Russian key it works in both layouts - Russian and English. Probably this is only a coinsidence though.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: [PATCH] Fix input keys in non-English locale in Linux

#4 Post by Geoff the Medio »

zhur wrote:...it seems like this isn't possible without modification of OIS
Since OIS is in the FreeOrion repository, that can be done.
* When LinuxKeyboard::capture is called it stores a keycode in event.xkey.keycode
* But when LinuxKeyboard::_injectKeyDown is called later it is only passed a KeySym key and UTF32 character
* LinuxKeyboard::_injectKeyDown finds a correspondence of X11 KeySym to OIS KeyCode and calls OISInput::keyPressed with a found corresponding KeyCode kc (KC_UNASSIGNED for non-English KeySyms)

That means that keycode (and even KeySym) is actually lost inside of libOIS and I have no idea how to get it back. Maybe to we can have a reverse mapping of UTF32 character into a GG Key? But that sounds too hack-ish.
Can you determine the KeyCode for the pressed key from the XEvent event's xkey property (similar to what XLookupSTring is doing to get a KeySym from the xkey property)? I don't know how XLookupString works or how a KeySym is different from a KeyCode, but it doesn't appear to be using any information besides event.xkey and the OS' internal settings to determine what to put in the buffer and the KeySym. If a KeyCode can be determined, it could be passed to (a modified) _injectKeyDown instead of a KeySym, since the passed in KeySym is presently only used to look up a KeyCode in _injectDown.

Edit: It appears that event.xkey is a XKeyEvent which has a keycode property.
I just tried Wesnoth (AFAIK also using OIS but CeGUI instead of GG) and they don't handle standard hotkeys when I am using Russian layout. Funny thing is that if I set some hotkey to a Russian key it works in both layouts - Russian and English. Probably this is only a coinsidence though.
That sounds like Wesnoth is working as as FreeOrion does in Windows: hotkeys are based on the hardware key that was pressed, so don't depend on the language setting. The question is how is Wesnoth getting the correct KeyCode from OIS on Linux when languages are set; it must be doing something different from what FO's version of OIS is doing, perhaps similar to what I suggested above.

Edit: I'm a bit skeptical about the Wesnoth OIS claim, as a quick peek at some code suggests it's SDL.

zhur
Space Floater
Posts: 38
Joined: Thu Aug 09, 2012 8:15 am

Re: [PATCH] Fix input keys in non-English locale in Linux

#5 Post by zhur »

Geoff the Medio wrote:Since OIS is in the FreeOrion repository, that can be done.
Right now FreeOrion uses system libOIS on Linux. And I can't find building scripts in the OIS folder. Don't you think it would be an overkill to add a new build step, new scripts and new features - just to get a fix for a problem that appears on only one platform (Linux), that can bother only part of the users (using non-English layout), and doesn't even matter for some of them (not using hotkeys or switching layouts for using them)? :roll:
Geoff the Medio wrote:Can you determine the KeyCode for the pressed key from the XEvent event's xkey property (similar to what XLookupSTring is doing to get a KeySym from the xkey property)? I don't know how XLookupString works or how a KeySym is different from a KeyCode, but it doesn't appear to be using any information besides event.xkey and the OS' internal settings to determine what to put in the buffer and the KeySym. If a KeyCode can be determined, it could be passed to (a modified) _injectKeyDown instead of a KeySym, since the passed in KeySym is presently only used to look up a KeyCode in _injectDown.

Edit: It appears that event.xkey is a XKeyEvent which has a keycode property.
Yes, there is a keycode property and it corresponds to the hardware button that was pressed (not a symbol that is written on the key - that's what a KeySym is, as I understand). I checked and it's the same when I press a button with whatever layout is currently active.
Geoff the Medio wrote:Edit: I'm a bit skeptical about the Wesnoth OIS claim, as a quick peek at some code suggests it's SDL.
Right, sorry - I must have mistaken it for something else.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: [PATCH] Fix input keys in non-English locale in Linux

#6 Post by Geoff the Medio »

zhur wrote:Right now FreeOrion uses system libOIS on Linux. And I can't find building scripts in the OIS folder.
I didn't include them, but they are available from the OIS SVN repository. The ReadMe (in the FO SVN or in OIS SVN) makes it look very simple to build.
Don't you think it would be an overkill to add a new build step, new scripts and new features - just to get a fix for a problem that appears on only one platform (Linux), that can bother only part of the users (using non-English layout), and doesn't even matter for some of them (not using hotkeys or switching layouts for using them)? :roll:
The extra building would also only be added for Linux, as presently OSX and Win32 use their own build environments, which actually do include building OIS from the code in FreeOrion SVN. And I do consider non-English keyboard layouts on Linux to be important users, who we should make a reasonable effort to support.
Yes, there is a keycode property and it corresponds to the hardware button that was pressed (not a symbol that is written on the key - that's what a KeySym is, as I understand). I checked and it's the same when I press a button with whatever layout is currently active.
Hmm. For some reason the keyboard handler on Windows passes that (or equivalent) info through, wheras the Linux version doesn't, resulting in the different behaviours.

zhur
Space Floater
Posts: 38
Joined: Thu Aug 09, 2012 8:15 am

Re: [PATCH] Fix input keys in non-English locale in Linux

#7 Post by zhur »

Geoff the Medio wrote:I didn't include them, but they are available from the OIS SVN repository. The ReadMe (in the FO SVN or in OIS SVN) makes it look very simple to build.
Nice. I'll try to import them back then.
Geoff the Medio wrote:The extra building would also only be added for Linux, as presently OSX and Win32 use their own build environments, which actually do include building OIS from the code in FreeOrion SVN. And I do consider non-English keyboard layouts on Linux to be important users, who we should make a reasonable effort to support.
Thanks, I appreciate it... :wink:
Geoff the Medio wrote:Hmm. For some reason the keyboard handler on Windows passes that (or equivalent) info through, wheras the Linux version doesn't, resulting in the different behaviours.
Here, the patch tries to do it. It was much simpler than I thought. With this change I can select next fleet with 'п' ('g') when Russian layout is selected! It's under GPLv2 or later as usual...
Attachments

[The extension patch has been deactivated and can no longer be displayed.]


Post Reply