html5 client keyboard mapping can't type symbols

[totaam]

Issue migrated from trac ticket # 837

component: client | priority: major | resolution: fixed | keywords: html5 client keyboard mapping

2015-04-18 15:52:39: joshiggins created the issue

---

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']))

[totaam]

2015-04-18 15:55:38: joshiggins changed status from new to assigned

[totaam]

2015-04-18 15:55:38: joshiggins changed owner from antoine to joshiggins

[totaam]

2015-04-18 18:10:01: antoine commented

---

@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.

[totaam]

2015-04-19 07:49:27: antoine changed status from assigned to new

[totaam]

2015-04-19 07:49:27: antoine commented

---

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.

[totaam]

2015-04-21 13:41:54: antoine changed owner from joshiggins to extasic

[totaam]

2015-04-21 13:41:54: antoine commented

---

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

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.

[totaam]

2015-04-28 04:27:05: antoine changed status from new to closed

[totaam]

2015-04-28 04:27:05: antoine set resolution to fixed

[totaam]

2015-04-28 04:27:05: antoine commented

---

Not heard back closing.