xpra icon
Bug tracker and wiki

Opened 4 years ago

Closed 16 months ago

Last modified 16 months ago

#371 closed task (fixed)

use X11 keyboard API instead of execing new processes

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: blocker Milestone: 0.16
Component: keyboard Version:
Keywords: Cc:

Change History (18)

comment:1 Changed 4 years ago by Antoine Martin

Milestone: 1.00.11
Status: newassigned

comment:2 Changed 3 years ago by Antoine Martin

Milestone: 0.110.12
Priority: majorcritical

priority for 0.12

comment:3 Changed 3 years ago by Antoine Martin

Milestone: 0.121.0

Re-scheduling because of lack of demand for this.

comment:4 Changed 3 years ago by Antoine Martin

Milestone: 1.00.16

Scheduling for 0.16 - see also #668, #759

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:5 Changed 22 months ago by 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)

comment:6 Changed 22 months ago by Antoine Martin

Description: modified (diff)

comment:7 Changed 21 months ago by Antoine Martin

Priority: criticalblocker

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

Last edited 17 months ago by Antoine Martin (previous) (diff)

comment:8 Changed 17 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

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

@afarr: can you?

comment:9 Changed 17 months ago by maxmylyn

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.

comment:10 Changed 17 months ago by maxmylyn

Found a minor issue:

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

comment:11 Changed 17 months ago by 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.

comment:12 Changed 17 months ago by 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.

comment:13 Changed 17 months ago by 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.

comment:14 Changed 17 months ago by alas

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

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

comment:15 Changed 16 months ago by 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

comment:16 Changed 16 months ago by alas

Owner: changed from alas to Antoine Martin

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.

comment:17 Changed 16 months ago by Antoine Martin

Resolution: fixed
Status: newclosed

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.

comment:18 Changed 16 months ago by Antoine Martin

Component: serverkeyboard
Summary: xkbcommon code to replace core keyboard and xkb callsuse X11 keyboard API instead of execing new processes

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

Note: See TracTickets for help on using tickets.