Xpra: Ticket #1607: Cannot switch between more than 2 XKB layouts

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.

Sat, 29 Jul 2017 19:31:40 GMT - Antoine Martin: owner changed

Please provide as many details as you can, as per wiki/Keyboard. And I have no idea how to use such layouts..

Sat, 29 Jul 2017 21:11:14 GMT - chaanakya: attachment set

My xmodmap configuration

Sat, 29 Jul 2017 21:16:41 GMT - chaanakya:

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)
mod4        Super_L (0x3e),  Super_R (0x86),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  ISO_Level3_Shift (0x87),  Mode_switch (0xcb)

Sat, 29 Jul 2017 21:19:21 GMT - chaanakya: attachment set

Output of xmodmap -pke

Sat, 29 Jul 2017 21:24:35 GMT - chaanakya: attachment set

Debug output

Sat, 29 Jul 2017 21:26:40 GMT - chaanakya: attachment set

Output of keymap.py

Mon, 28 Aug 2017 04:47:43 GMT - Antoine Martin: description changed

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
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'))"


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?

Sun, 01 Oct 2017 10:04:36 GMT - Antoine Martin: status changed; resolution set

Not heard back, will try to deal with this in #1049.

Mon, 04 Dec 2017 09:02:12 GMT - Antoine Martin:

See #1380 which may be sufficient if your client OS uses X11.

Sat, 23 Jan 2021 05:28:58 GMT - migration script:

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