I have set up XKB using
setxkbmap -layout us,in,in -variant ,kan-kagapa,hin-kagapa -option -option grp:menu_toggle -option ctrl:swap_caps -option grp_led:num
On regular X windows, this works fine - I can switch between all 3 layouts without any issues. Within Xpra, however, the keyboard refuses to output anything on the third layout (hin-kagapa). That is, it switches to that layout, but then does not type anything. I'm using revision r16525.
Please provide as many details as you can, as per wiki/Keyboard. And I have no idea how to use such layouts..
My xmodmap configuration
Active keyboard layout(s): us,in(kan-kagapa),in(hin-kagapa) (I don't think the exact keyboard layouts matter though...this should be true of any 3 layouts)
Input methods: Not using any at the moment - switched exclusively to xkb
Keyboard-related configuration setup/files: See my .xmodmap attached above
Keyboard type: Standard laptop keyboard (pc105 with evdev rules)
Debug log output: I will upload this in a bit
Whether the bug is present with/without --no-keyboard-sync
: yes
setxkbmap -print
output:
xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete+lednum(group_lock)" }; xkb_symbols { include "pc+us+in:2+in:3+inet(evdev)+group(rctrl_toggle)+ctrl(swapcaps)" }; xkb_geometry { include "pc(pc105)" }; };
setxkbmap -query
output:
rules: evdev model: pc105 layout: us,in,in options: grp:rctrl_toggle,ctrl:swapcaps,grp_led:num
xpra/gtk_common/keymap.py
: I will upload in a bit
xmodmap -pke
output: I will attach output in a bit
xmodmap -pm
output:
xmodmap: up to 4 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x85), Shift_R (0xce) lock Caps_Lock (0x25) control Control_L (0x42) mod1 Alt_R (0x31), Alt_L (0x40), Alt_L (0xcc), Meta_L (0xcd) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x3e), Super_R (0x86), Hyper_L (0xcf) mod5 ISO_Level3_Shift (0x5c), ISO_Level3_Shift (0x87), Mode_switch (0xcb)
Output of xmodmap -pke
Debug output
Output of keymap.py
In the log I see samples like this one:
process_key_action(['key-action', 1, 'U093E', True, (), 16779582, '\xe0\xa4\xbe', 38, 2]) server keycode=38 filtered_modifiers_set([])=set([]) filtered_modifiers_set([])=set([]) handle_key(1,True,U093E,16779582,38,()) keyboard_sync=True is_modifier(38) not found handle keycode pressing 38: key U093E fake_key(38, True)
So the unicode character U093E
is requested and we press keycode 38
for it.
Keycode 38 is defined in the xmodmap as:
keycode 38 = a A U0CBE U0C86 NoSymbol NoSymbol U0C85 NoSymbol U093E U0906 U0905 U0972
The string given matches the unicode value:
$ python -c "print('\xe0\xa4\xbe'.decode('utf8'))" ा
Which is DEVANAGARI VOWEL SIGN AA.
My guess is that we don't map the full keycode because we are limited to just 8 symbols when we use the core API, we would need to switch to xkb: #1049.
You can confirm that by attaching the xmodmap -pke
from within the xpra session. I assume that the one you attached is from the client?
Not heard back, will try to deal with this in #1049.
See #1380 which may be sufficient if your client OS uses X11.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1607