When connecting to Xpra from the HTML5 client, the system attempts to obtain the keyboard layout from the browser's reported language - unfortunately, in my particular case this is causing wrong guesses, namely:
In both cases, this causes the inability to type into any windows. Xterm in particular only seems to display numbers and a few control characters. Not even setting the server to use a specific keyboard layout through the --keyboard-layout=XX command seems to work, as the layout is dynamically switched because of the heuristics detailed above. This bug might have gone unnoticed before, because there are EN and US layouts available by default.
So, the difficulty here is that the browsers return List all valid kbd layouts, variants and toggle options (to use with setxkbmap)).
The original code was trying to make sure that when we get
en_GB then we will use the
gb x11 keymap.
en, we should use
And in your case, for
ES-ar we should be using
es or maybe
latam? Is there an
ar variant? If so, how do we configure that variant with X11?
So r24878 changes the detection code to do that, using the primary language and adding entries to the existing
LANGUAGE_TO_LAYOUT lookup table.
I couldn't see an easy way of automatically mapping the ISO codes to X11 layouts... so I did it by hand: r24879 - that took a while. And it is still incomplete as some locales don't have an obvious X11 language mapping, and new locales may be added to browsers, and some are probably missing from the list I used to begin with...
@csolisr: does that work for you? You can apply the patches by hand, download a new copy of the html5 client code from svn, or use the latest online version here: https://xpra.org/html5/
Not heard back, closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2241