use X11 keyboard API instead of execing new processes

[Antoine Martin]

• ​xkbcommon docs
• Keyboard wiki
• ​xkb docs

[Antoine Martin]

priority for 0.12

[Antoine Martin]

Re-scheduling because of lack of demand for this.

[Antoine Martin]

Scheduling for 0.16 - see also #668, #759

[Antoine Martin]

r9532 deals with setxkbmap. Setting the keymap is now done fully through our existing X11 server connection without execing any new processes.

I will need to do more testing with "exotic" keyboard layouts to see if the call we had to xkbcomp should have been preserved. (in which case this would have to be re-written using Cython too - I hope not, the ​xkbcomp source code is scary)

[Antoine Martin]

Blocker for #817, see also #824, #759, #923, #939?

[Antoine Martin]

Done some testing with "fr" layout, couldn't break it.

@afarr: can you?

[J. Max Mena]

Tested with a myriad of layouts with a Win8.1 trunk r11099 client against a Fedora 21 trunk r11099 Server:

• Couldn't break it...although the system didn't recognize my Georgian input..probably because I don't have that keyboard or language enabled on the server....Russian worked though.

• I could spend a lot more time with more keyboard layouts and writing systems, but for all the ones that share a writing system with English (fr, de(Schweiz, Deutschland), dk, etc) it appears to be working just fine.

[J. Max Mena]

Found a minor issue:

• With the English-International keyboard layout, inputting " (by hitting " twice) gives me ¨ on the server through Xpra.

[alas]

• Gave it a little run with osx (0.16 r11077) - Hebrew worked as well as I could tell, Farsi looked good (though I wasn't sure about some of the Apple transliteration choices... not the keyboard's fault though), and Spanish seemed alright - osx key mappings aside, again.

[Antoine Martin]

With the English-International keyboard layout, inputting " (by hitting " twice) gives me ¨ on the server through Xpra.

That doesn't sound like too much of a problem.
It's worth checking which input methods are in use, if any. And maybe try a different one: see #634.

Also, it may be worth testing #817 at the same time.

[alas]

Testing inputting with Hebrew and Spanish keyboard layouts with windows 8.1, as long as the language is set before connection (see #817, regarding changing keyboard input layout "on the fly" with windows clients).

I took a quick stab at setting --input-method=uim, which seemed to behave about the same. Not sure how to check what input methods are being used without the use of flags to set them explicitly though.

[alas]

Interesting... I tried to use Hindi keyboard layout (HI - Hindi traditional layout).

• Followed steps suggested at ​https://fedoraproject.org/wiki/I18N/Language_Support_Using_Yum to install the support on the fedora 21 vm (sudo yum groupinstall hindi-support & sudo yum langinstall hi_IN).

• Installed the keyboard layout.

• Set things up, switched keyboard layout, connected to a session.

I wasn't able to input any Devanagari script characters into a browser, an xterm, or a gedit application - but I was able to input them into the Run command buffer of the tray menu (typing 'xterm' in as 'ंूाीस' was not successful in launching anything, unsurprisingly).

Reconnecting with -d keyboard, the keyboard key 'k' (which does correctly correspond to 'क', for what that's worth) outputs the following client side:

2015-11-12 17:16:12,841 parse_key_event(<gtk.gdk.Event at 06496590: GDK_KEY_PRESS keyval=U+0915>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group
': 0, 'string': '', 'keyname': 'U+0915', 'pressed': True, 'keyval': 16779541, 'keycode': 75}>
2015-11-12 17:16:12,841 handle_key_action(GLClientWindow(10 : gtk2.GLWindowBacking(10, (900, 700), None)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'gr
oup': 0, 'string': '', 'keyname': 'U+0915', 'pressed': True, 'keyval': 16779541, 'keycode': 75}>) wid=10
2015-11-12 17:16:12,841 send_key_action(10, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'U+0915', 'pressed': True, 'k
eyval': 16779541, 'keycode': 75}>)
2015-11-12 17:16:13,013 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-12 17:16:13,013 parse_key_event(<gtk.gdk.Event at 064966B0: GDK_KEY_RELEASE keyval=U+0915>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'gr
oup': 0, 'string': '', 'keyname': 'U+0915', 'pressed': False, 'keyval': 16779541, 'keycode': 75}>
2015-11-12 17:16:13,029 handle_key_action(GLClientWindow(10 : gtk2.GLWindowBacking(10, (900, 700), None)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'gr
oup': 0, 'string': '', 'keyname': 'U+0915', 'pressed': False, 'keyval': 16779541, 'keycode': 75}>) wid=10
2015-11-12 17:16:13,029 send_key_action(10, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'U+0915', 'pressed': False, '
keyval': 16779541, 'keycode': 75}>)

Server side:

2015-11-12 17:27:53,650 get_keycode(75, U+0915, ('mod2',)) is_native_keymap=False, found using translation: 145
2015-11-12 17:27:53,652 handle_key(2,True,U+0915,16779541,145,('mod2',)) keyboard_sync=True
2015-11-12 17:27:53,652 is_modifier(145) not found
2015-11-12 17:27:53,653 handle keycode pressing 145: key U+0915
2015-11-12 17:27:53,653 fake_key(145, True)
2015-11-12 17:27:53,656 scheduling key repeat timer with delay 500 for U+0915 / 145
2015-11-12 17:27:53,778 get_keycode(75, U+0915, ('mod2',)) is_native_keymap=False, found using translation: 145
2015-11-12 17:27:53,779 handle_key(2,False,U+0915,16779541,145,('mod2',)) keyboard_sync=True
2015-11-12 17:27:53,779 is_modifier(145) not found
2015-11-12 17:27:53,780 handle keycode unpressing 145: key U+0915
2015-11-12 17:27:53,780 fake_key(145, False)
2015-11-12 17:27:56,720 _clear_keys_pressed()

It looks like this language/keyboard mapping isn't being found by the server? (Do you need/reluctantly want the full log output of a connection with that keyboard input setting to check on this?... looking through it myself, it looks like there is no recognition of the characters - just numerical values assigned to keyvals.)

(More searching among "exotic" layouts to come.)

[Antoine Martin]

The keycode is being found:

get_keycode(75, U+0915, ('mod2',)) is_native_keymap=False, found using translation: 145

You should be able to see this key mapping on the server with:

./xpra/gtk_common/keymap.py  | grep 145

Or

xmodmap -pke | grep 145

[alas]

Interestingly, when I run ./xpra/gtk_common/keymap.py | grep 145, I get no response from the server.

When I run xmodmap -pke | grep 145, on the other hand, it does seem to recognize the mapping: keycode 145 = 0x0915 0x0916 0x0915 0x0916 0x0915 0x0916

I still can't get the Hindi or Sanskrit characters (Devanagari) to display - but judging from the searches I've done on the subject, I'm not alone in that failure.

I haven't been able to find any other issues with any "exotic" keyboard layouts with the new xkbcommon code though. Handing this back - looks ready to close.

[Antoine Martin]

I get no response from the server.

My guess is that you didn't run it against the display. You have to run this command within an xterm started in the session, or manually set the DISPLAY.

Closing. If we get bug reports about specific layouts, we can make new tickets and point back here.

[Antoine Martin]

Clarification: this only dealt with making API calls, actual Xkb will be dealt with in #1049.

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/371