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']))
@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.
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.
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.
Not heard back closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/837