xpra icon
Bug tracker and wiki

Opened 3 years ago

Closed 2 years ago

#837 closed defect (fixed)

html5 client keyboard mapping can't type symbols

Reported by: Josh Owned by: extasic
Priority: major Milestone: 0.14
Component: client Version: trunk
Keywords: html5 client keyboard mapping Cc: extasic

Description

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

Change History (5)

comment:1 Changed 3 years ago by Josh

Owner: changed from Antoine Martin to Josh
Status: newassigned

comment:2 Changed 3 years ago by Antoine Martin

Milestone: 0.14

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

comment:3 Changed 3 years ago by Antoine Martin

Status: assignednew

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.

Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:4 Changed 2 years ago by Antoine Martin

Owner: changed from Josh to extasic

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.

comment:5 Changed 2 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

Not heard back closing.

Note: See TracTickets for help on using tickets.