Bug 1183025

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é