Xpra: Ticket #1055: right shift key is mapped to '7' with html5 client

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.



Wed, 16 Dec 2015 08:31:16 GMT - Antoine Martin: owner changed

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.


Thu, 17 Dec 2015 23:48:03 GMT - J. Max Mena: status changed; resolution set

Tested with a r11425 trunk Fedora 23 server, connected from Google Chrome:

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.


Fri, 18 Dec 2015 02:24:44 GMT - Antoine Martin:

numlock has its own ticket: #858


Sat, 23 Jan 2021 05:13:40 GMT - migration script:

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