Xpra: Ticket #837: html5 client keyboard mapping can't type symbols

Some special characters cannot be typed in the html 5 client. Most notably, the period symbol.

It seems that all letters and numbers are mapped correctly.

Observed with english US, UK and german layouts but not sure it is related to the client's keyboard layout.

Server complains when connecting:

2015-04-18 14:20:47,365 set_keycodes: no free keycodes!, cannot translate -1: set([('greater', 1), ('period', 2), ('period', 0), ('greater', 3)])
2015-04-18 14:20:47,366 set_keycodes: no free keycodes!, cannot translate -1: set([('slash', 2), ('question', 1), ('slash', 0), ('question', 3)])
2015-04-18 14:20:47,366 set_keycodes: no free keycodes!, cannot translate -1: set([('asciitilde', 3), ('grave', 2), ('grave', 0), ('asciitilde', 1)])
2015-04-18 14:20:47,366 set_keycodes: no free keycodes!, cannot translate -1: set([('braceright', 3), ('bracketright', 2), ('bracketright', 0), ('braceright', 1)])
2015-04-18 14:20:47,366 set_keycodes: no free keycodes!, cannot translate -1: set([('bracketleft', 2), ('bracketleft', 0), ('braceleft', 3), ('braceleft', 1)])
2015-04-18 14:20:47,366 set_keycodes: no free keycodes!, cannot translate -1: set([('apostrophe', 2), ('apostrophe', 0), ('quotedbl', 3), ('quotedbl', 1)])
2015-04-18 14:20:47,366 set_keycodes: no free keycodes!, cannot translate -1: set([('Hyper_R', 0)])
2015-04-18 14:20:47,373 xmodmap_exec_add: no keycodes found for keysym Hyper_R/65518
2015-04-18 14:20:47,373 native_xmodmap could not handle instruction: ('add', 6, set(['Hyper_R', 'Hyper_L']))
2015-04-18 14:20:47,384 xmodmap_exec_add: no keycodes found for keysym Hyper_R/65518
2015-04-18 14:20:47,384 native_xmodmap could not handle instruction: ('add', 6, set(['Hyper_R', 'Hyper_L']))
2015-04-18 14:20:47,385 removing problematic modifier mapping: ('add', 6, set(['Hyper_R', 'Hyper_L']))


Sat, 18 Apr 2015 14:55:37 GMT - Josh: owner, status changed


Sat, 18 Apr 2015 17:10:01 GMT - Antoine Martin: milestone set

@joshiggins: I'll take a better look tomorrow. I can reproduce it but I'm not sure what the right solution is yet. Generally speaking, maybe we should prioritize which keys get mapped (things like the period are much more likely to be important than a lot of the media keys (like XF86KbdBrightnessDown), especially for the html5 client.


Sun, 19 Apr 2015 06:49:27 GMT - Antoine Martin: status changed

r9054 fixes this for me (we skip the XF* keys to try harder to fit the other keys into the keymap). I will backport to v0.14.x once this is tested a bit more for regressions. (feel free to re-assign to afarr for that)

Word of warning: this is a bit of hack - but then again, the whole keymapping code is just a huge pile of hacks already, and this may actually help with key mapping issues with other non-X11 clients with exotic keymaps.

Also, this may not even be needed, there is already a "period" keycode in the keymap, and after this changeset we now get two:

$ DISPLAY=:1 xmodmap -pke | grep period
keycode  60 = period greater period greater periodcentered division periodcentered
keycode 163 = period greater period greater periodcentered division periodcentered

Why didn't the first one get matched when we try to map the entries?? I'll try to take another look when I get a chance. I have added in r9055 an env var to make it easier to debug specific keysyms (since the default -d keyboard debugging output is just too verbose), ie:

XPRA_DEBUG_KEYSYMS="Shift_L,period" python2 /usr/bin/xpra start

PS: very minor fixes in r9052 + r9053.


Tue, 21 Apr 2015 12:41:53 GMT - Antoine Martin: owner changed

The backport to the v0.14.x branch is in r9083.

Then I took another look and found the real culprit: r9095 ensures we don't double map keycodes and actually use the translation table instead. This one could also be backported, but no rush - it's potentially more problematic.

@extasic: does this work for you? if so, please close the ticket.


Tue, 28 Apr 2015 03:27:04 GMT - Antoine Martin: status changed; resolution set

Not heard back closing.


Sat, 23 Jan 2021 05:07:29 GMT - migration script:

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