My setup:
A libvirt/qemu virtual guest using the VNC protocol. The virtual guest is
configured with 'loadkeys no'. libvirt/qemu based hypervisor runs Scientific
Linux 6 (RHEL6 clone). OS on the virtual guest is Scientific Linux 7 (RHEL7
clone)
A Linux desktop (flavour doesn't really matter, but tested on RHEL7 and a few
Fedora releases) which runs the tigervnc client against the libvirt/qemu
hypervisor.
The core issue - mismatch in keyboard mapping
If the keyboard in my desktop environment on tigervnc client side is set up to 'English US' the keyboard layout inside the guest works flawlessly.
If the keyboard in my desktop environment is set to 'Norwegian', the virtual guest keyboard is completely messed up.
If the keyboard in my desktop environment is set to 'Norwegian' and the virtual guest keyboard is configured with 'loadkeys us', the keyboard mapping is even weirder.
So there is a keyboard mapping which is doing the wrong thing and it seems to expects the client side to be using the 'US' keyboard mapping. Instead I believe the correct behaviour would be to not do any client side mapping but to pass over the scan codes directly, regardless of the client side keyboard mapping.
Software versions:
Client side: tigervnc-1.2.80-0.30.20130314svn5065.el7.x86_64
Hypervisor: qemu-kvm-0.12.1.2-2.448.el6_6.4.x86_64
libvirt-0.10.2-46.el6_6.6.x86_64
It is general issue of RFB protocol: http://www.realvnc.com/docs/rfbproto.pdf
Client always use its own layout to form <x11 keysymdef.h=""> key values.</x11>