Xpra: Ticket #371: use X11 keyboard API instead of execing new processes

Tue, 16 Jul 2013 05:43:55 GMT - Antoine Martin: status, milestone changed

Thu, 17 Oct 2013 07:46:15 GMT - Antoine Martin: priority, milestone changed

priority for 0.12

Mon, 20 Jan 2014 11:11:22 GMT - Antoine Martin: milestone changed

Re-scheduling because of lack of demand for this.

Tue, 19 Aug 2014 04:03:57 GMT - Antoine Martin: milestone changed

Scheduling for 0.16 - see also #668, #759

Wed, 27 May 2015 17:13:23 GMT - 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)

Sun, 07 Jun 2015 19:53:09 GMT - Antoine Martin: description changed

Fri, 19 Jun 2015 08:39:28 GMT - Antoine Martin: priority changed

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

Fri, 30 Oct 2015 09:51:11 GMT - Antoine Martin: owner, status changed

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

@afarr: can you?

Fri, 30 Oct 2015 19:11:16 GMT - J. Max Mena:

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

Fri, 30 Oct 2015 19:24:34 GMT - J. Max Mena:

Found a minor issue:

Sat, 31 Oct 2015 01:15:49 GMT - alas:

Mon, 02 Nov 2015 05:17:38 GMT - 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.

Thu, 05 Nov 2015 00:58:24 GMT - 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.

Fri, 13 Nov 2015 01:39:17 GMT - alas:

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

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.)

Fri, 20 Nov 2015 05:22:50 GMT - 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


xmodmap -pke | grep 145

Fri, 20 Nov 2015 19:59:00 GMT - alas: owner changed

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.

Sun, 22 Nov 2015 06:58:23 GMT - Antoine Martin: status changed; resolution set

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.

Wed, 09 Dec 2015 05:25:51 GMT - Antoine Martin: component, summary changed

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

Sat, 23 Jan 2021 04:53:18 GMT - migration script:

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