#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: |
Description (last modified by )
Change History (19)
comment:1 Changed 8 years ago by
Milestone: | 1.0 → 0.11 |
---|---|
Status: | new → assigned |
comment:2 Changed 7 years ago by
Milestone: | 0.11 → 0.12 |
---|---|
Priority: | major → critical |
comment:3 Changed 7 years ago by
Milestone: | 0.12 → 1.0 |
---|
Re-scheduling because of lack of demand for this.
comment:4 Changed 7 years ago by
Milestone: | 1.0 → 0.16 |
---|
comment:5 Changed 6 years ago by
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 6 years ago by
Description: | modified (diff) |
---|
comment:7 Changed 6 years ago by
Priority: | critical → blocker |
---|
comment:8 Changed 5 years ago by
Owner: | changed from Antoine Martin to alas |
---|---|
Status: | assigned → new |
Done some testing with "fr" layout, couldn't break it.
@afarr: can you?
comment:9 Changed 5 years ago by
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 5 years ago by
Found a minor issue:
- With the English-International keyboard layout, inputting
"
(by hitting " twice) gives me¨
on the server through Xpra.
comment:11 Changed 5 years ago by
- 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 5 years ago by
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 5 years ago by
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 5 years ago by
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.)
comment:15 Changed 5 years ago by
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 5 years ago by
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 5 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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 5 years ago by
Component: | server → keyboard |
---|---|
Summary: | xkbcommon code to replace core keyboard and xkb calls → use X11 keyboard API instead of execing new processes |
Clarification: this only dealt with making API calls, actual Xkb will be dealt with in #1049.
comment:19 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/371
priority for 0.12