HTML5 client. Sounds like an easy problem... but keyboard rarely is.
Some debugging output with -d keyboard
:
2015-12-16 13:45:27,266 get_keycode(16, Shift_R, ['shift']) native keymap, using unmodified keycode: 16 2015-12-16 13:45:27,267 filtered_modifiers_set([])= 2015-12-16 13:45:27,267 modifier shift ignored (in ignored keynames=set(['Shift_L', 'Shift_R'])) 2015-12-16 13:45:27,267 filtered_modifiers_set(['shift'])= 2015-12-16 13:45:27,267 handle_key(1,1,Shift_R,16,16,['shift']) keyboard_sync=True 2015-12-16 13:45:27,267 handle keycode pressing 16: key Shift_R 2015-12-16 13:45:27,267 fake_key(16, True) 2015-12-16 13:45:27,268 modifier_map({})={'control': 4, 'mod1': 8, 'mod2': 16, 'mod3': 32, 'mod4': 64, 'mod5': 128, 'lock': 2, 'num': 0, 'hyper': 0, 'meta': 0, 'shift': 1, 'alt': 0, 'super': 0, 'scroll': 0} 2015-12-16 13:45:27,268 compute_modifier_keynames: keycodes_for_modifier_keynames={'ISO_Level3_Shift': set([113, 124]), 'Mode_switch': set([8]), 'Meta_L': set([64, 156]), 'Control_R': set([109]), 'Super_R': set([116]), 'Alt_R': set([131]), 'Hyper_L': set([128]), 'Caps_Lock': set([66]), 'Hyper_R': set([132]), 'Alt_L': set([64, 125]), 'Num_Lock': set([77]), 'Super_L': set([115, 127]), 'Shift_R': set([62]), 'Meta_R': set([133]), 'Control_L': set([37]), 'Shift_L': set([50])} 2015-12-16 13:45:27,268 keys_changed() updated keyboard config=KeyboardConfig(gb / None) 2015-12-16 13:45:27,402 get_keycode(16, Shift_R, []) native keymap, using unmodified keycode: 16 2015-12-16 13:45:27,402 filtered_modifiers_set([])= 2015-12-16 13:45:27,403 filtered_modifiers_set([])= 2015-12-16 13:45:27,403 handle_key(1,0,Shift_R,16,16,[]) keyboard_sync=True 2015-12-16 13:45:27,403 handle keycode unpressing 16: key Shift_R 2015-12-16 13:45:27,403 fake_key(16, False) 2015-12-16 13:45:27,570 get_keycode(16, Shift_R, ['shift']) native keymap, using unmodified keycode: 16 2015-12-16 13:45:27,570 filtered_modifiers_set([])= 2015-12-16 13:45:27,570 modifier shift ignored (in ignored keynames=set(['Shift_L', 'Shift_R'])) 2015-12-16 13:45:27,570 filtered_modifiers_set(['shift'])= 2015-12-16 13:45:27,570 handle_key(1,1,Shift_R,16,16,['shift']) keyboard_sync=True 2015-12-16 13:45:27,571 handle keycode pressing 16: key Shift_R 2015-12-16 13:45:27,571 fake_key(16, True) 2015-12-16 13:45:27,658 get_keycode(16, Shift_R, []) native keymap, using unmodified keycode: 16
Server mapping:
2015-12-16 13:45:19,132 get_modifiers_from_keycodes(...)={'control': set(['Control_L', 'Control_R']), 'mod1': set(['Meta_R', 'Alt_R', 'Meta_L', 'Alt_L']), 'mod2': set(['Num_Lock']), 'mod3': set(['Super_R', 'Super_L']), 'mod4': set(['Hyper_R', 'Hyper_L']), 'mod5': set(['ISO_Level3_Shift', 'Mode_switch']), 'shift': set(['Shift_L', 'Shift_R']), 'lock': set(['Caps_Lock'])} ... 2015-12-16 13:45:19,141 preserved mappings: 2015-12-16 13:45:19,142 16 = ['7', 'ampersand', '7', 'ampersand', 'braceleft', 'seveneighths', 'braceleft'] 2015-12-16 13:45:19,143 50 = ['Shift_L', '', 'Shift_L'] 2015-12-16 13:45:19,144 62 = ['Shift_R', '', 'Shift_R'] 2015-12-16 13:45:19,167 found direct preserve superset for client keycode 16 (('Shift_L', 0),) -> server keycode 50 (('Shift_L', 0), ('Shift_L', 2)) 2015-12-16 13:45:19,275 set_keycodes key -1 ((('Shift_R', 2), ('Shift_R', 0))) mapped to keycode=62 2015-12-16 13:45:19,275 keycode_trans[Shift_R]=62
The problem is that we have two different keycodes for Shift_R
and Shift_L
in a normal keymap, but the html5 client will send both with the same keycode (16), the server fails to locate the matching key and then assumes this is a raw keycode: native keymap, using unmodified keycode: 16
.
The fix for the server is quite small: r11404 fixes how we detect native and non-native keymaps. This change could have some undesirable side-effects, especially this late in the 0.16 release cycle. So I am not backporting it, at least for now. It looks safe, as I tested before and after applying it with various clients using:
xpra start --no-daemon -d keyboard |& grep is_native_keymap
And the native keymap flag gives the same value as before for all the clients I tested (except for the HTML5 client which is now fixed): win32 and osx are not native, X11 is.
r11405 fixes this in a similar way, but only in the HTML5 client, so this is a lot less risky to apply to older branches - as long as this change does not create any other key mapping problems.
@afarr: applied to v0.15.x and v0.16.x in r11406, please test and close.
Edit: please make sure to test all keys and not just Shift_R
, as this changes how all keys get translated.
Tested with a r11425 trunk Fedora 23 server, connected from Google Chrome:
shift
in the log, rather than Shif_R
Tested with a r11425 15.X Fedora 23 server, connected from Google Chrome:
2015-12-17 15:41:36,356 get_keycode(72, h, ['shift']) is_native_keymap=False, found using translation: 43
Looks like nothing broke. Closing.
numlock has its own ticket: #858
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1055