[PATCH] Fix input keys in non-English locale in Linux
Moderator: Committer
[PATCH] Fix input keys in non-English locale in Linux
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.
* 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.]
- 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
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.
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.
Re: [PATCH] Fix input keys in non-English locale in Linux
I think it still needs at least some testing especially on Windows.Geoff the Medio wrote:That sounds like it will fix the typing issue with non-US keyboard layouts, which is good.
Exploring a little bit more it seems like this isn't possible without modification of OIS: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.
* 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.
- 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
Since OIS is in the FreeOrion repository, that can be done.zhur wrote:...it seems like this isn't possible without modification of OIS
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.* 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.
Edit: It appears that event.xkey is a XKeyEvent which has a keycode property.
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.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.
Edit: I'm a bit skeptical about the Wesnoth OIS claim, as a quick peek at some code suggests it's SDL.
Re: [PATCH] Fix input keys in non-English locale in Linux
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)?Geoff the Medio wrote:Since OIS is in the FreeOrion repository, that can be done.
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: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.
Right, sorry - I must have mistaken it for something else.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.
- 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
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.zhur wrote:Right now FreeOrion uses system libOIS on Linux. And I can't find building scripts in the OIS folder.
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.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)?
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.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.
Re: [PATCH] Fix input keys in non-English locale in Linux
Nice. I'll try to import them back then.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.
Thanks, I appreciate it...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.
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...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.
- Attachments
-
[The extension patch has been deactivated and can no longer be displayed.]