priority for 0.12
Re-scheduling because of lack of demand for this.
Scheduling for 0.16 - see also #668, #759
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)
Blocker for #817, see also #824, #759, #923, #939?
Done some testing with "fr" layout, couldn't break it.
@afarr: can you?
Tested with a myriad of layouts with a Win8.1 trunk r11099 client against a Fedora 21 trunk r11099 Server:
Found a minor issue:
"
(by hitting " twice) gives me ¨
on the server through Xpra.
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.
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.
Interesting... I tried to use Hindi keyboard layout (HI - Hindi traditional layout).
sudo yum groupinstall hindi-support
& sudo yum langinstall hi_IN
).
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.)
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
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.
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.
Clarification: this only dealt with making API calls, actual Xkb will be dealt with in #1049.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/371