xpra icon
Bug tracker and wiki

Opened 22 months ago

Closed 22 months ago

Last modified 22 months ago

#1055 closed defect (fixed)

right shift key is mapped to '7' with html5 client

Reported by: Antoine Martin Owned by: alas
Priority: critical Milestone: 0.16
Component: html5 Version: trunk
Keywords: Cc:

Description

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.

Change History (3)

comment:1 Changed 22 months ago by Antoine Martin

Owner: changed from Josh to alas

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.

Last edited 22 months ago by Antoine Martin (previous) (diff)

comment:2 Changed 22 months ago by J. Max Mena

Resolution: fixed
Status: newclosed

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

  • All keys work. (Still no NumLock? sync)
  • Hitting right shift shows up as a regular shift in the log, rather than Shif_R

Tested with a r11425 15.X Fedora 23 server, connected from Google Chrome:

  • All keys work. (Still no NumLock? sync, I swear I didn't copy paste this part)
  • Hitting right shift does not show up in the log. But, characters show up as uppercase(if typed with right shift held down..) and will print something like:
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.

comment:3 Changed 22 months ago by Antoine Martin

numlock has its own ticket: #858

Note: See TracTickets for help on using tickets.