Description of problem: I have been trying novnc with spanish language, some keys works but not AltGR, it apparently sends Alt instead of AltGR so characters like |@ can't be written. I have opened it upstream too: https://github.com/kanaka/noVNC/issues/429 there was a similar issue in the past with swedish keyboard layout https://github.com/kanaka/noVNC/issues/345 Version-Release number of selected component (if applicable): novnc-0.4-7.el7ost.noarch latest upstream version I have been trying novnc with spanish language, some keys works but it apparently sends Alt instead of AltGR so characters like |@ can't be written. I tested it with the latest version too. There is a similar isue reported before: How reproducible: Always Steps to Reproduce: -installed centos 6.5 cloud image -use system-config-keyboard to select spanish -update lang to LANG=es_ES.UTF8 Results: Accessing the instance via vncviewer I can type characters like @|, If i try to write @ (AltGr 2) I get the same result as Alt 2
I suspect that this is a duplicate of upstream bug 345, which was already fixed upstream. I have just tested with the latest version of noVNC (0.5.1) and `setxkbmap -layout es`, and was able to use AltGr to enter @ signs into noVNC.
Hi Solly, Is there some known workaround wrt this keyboard mapping issue with RHOSP8? Regards, Pierre-André
Right, so, the problem has to do with the strangeness that is keyboard handling and VNC. VNC mainly handles input by sending and receiving something a bit closer to the actual characters -- for instance, if I typed `Shift + 2` on a US keyboard, what VNC clients are supposed to send is `Shift + @`, since `Shift + 2` actually produces an `@` symbol on a standard US keyboard. This is all fine and dandy when your VNC server is running *inside* the operating system, and can deliver these keysyms appropriately. However, qemu's VNC server effectively operates *outside* the operating system, and thus has no concept of characters, only of something approximating physical keypresses on emulated keyboard hardware, so it tries to figure out that "@" is actually "2", and send the appropriate physical key presses. So, on to AltGr. When working inside the OS, AltGr becomes ISO_Level3_Shift. So, for instance, the appropriate keycodes to send for, say `XK_Alt_R + 2` are `XK_ISO_Level3_Shift + @`. However, AFAICT, qemu doesn't quite know what ISO_Level3_Shift maps to physically, since it's not a real key. noVNC master has a patch that uses a special extension to VNC that qemu supports which works around this by sending mappings of the physical key presses instead of their logical character equivalents. That patch should be old enough to be backportable (https://github.com/novnc/noVNC/pull/596). The alternative is this patch, which simply sends XK_Alt_R (which qemu knows how to handle) instead of XK_ISO_Level3_Shift. diff --git a/include/keyboard.js b/include/keyboard.js index 8667031..01c2ae9 100644 --- a/include/keyboard.js +++ b/include/keyboard.js @@ -266,7 +266,7 @@ var kbdUtil = (function() { case 18 : return XK_Alt_L; // also: Option-key on Mac case 224 : return XK_Meta_L; - case 225 : return XK_ISO_Level3_Shift; // AltGr + case 225 : return XK_Alt_R; // AltGr case 91 : return XK_Super_L; // also: Windows-key case 92 : return XK_Super_R; // also: Windows-key case 93 : return XK_Menu; // also: Windows-Menu, Command on Mac Note that this will only help in the case when the remote machine is set up to use a Spanish keyboard -- qemu's VNC connection works by converting sent key symbols back to physical keypresses (AFAIK), so if the remote machine is using a different keyboard layout, it'll work as if you'd hooked your keyboard up to the machine physically.
(note that the latter patch *might* break noVNC against non-qemu targets, since they're probably expecting the ISO_Level3_Shift behavior).
Thanks Solly, I've asked the customer to test the proposed modification. I'll report the results here. But if it works, how can we handle this properly as we don't want a custom noVNC for this customer only. My customer is running RHOSP8 with belgium keyboards. They plan to update to 9 and 10, starting early next year. Regards, Pierre-André