Currently VNC's keyboard model is sending symbols from the client and letting the server figure out how to map this to physical keys. Details about this model (and other ones) can be found on bug 3523. We should consider switching to the model where we send physical keys instead though. Advantages: - This is what everyone else<tm> is doing. Every other remote system I can think of uses physical keys, so it is what developers test against, and it is what users and administrators are used to. - Better compatibility with programs that need physical keys. This includes other remote desktop systems, virtualisation and emulation. - Better compatibility with programs that have fancy input handling. E.g. programs that want different behaviours for Lock and Shift, or that need to determine if you pressed Shift-Up independently of Num_Lock state. - Simplified model. There is no need for fake input under this model, so it's easier to grasp what's going on. - It is also very difficult to map from symbols back to keycodes in many cases, so we get rid of that entire mess (and all the bugs that keep popping up). Disadvantages: - Users will have to configure a keyboard layout for the session. We might be able to have some heuristics given that we can ship a well-known set of layouts, and that we have a limit set of supported client platforms. But it will never be 100% (on Unix at least). - It will required XKB on clients. Old clients will either have to be unsupported, or they'll have to make due with the old model. Windows and OS X are fine though. - If you mix in old clients/servers then there might be some confusion as the keyboard will behave differently compared to the newer stuff. This will resolve itself over time though and can be mitigated through warnings. An extension for this is already in place in VNC and in wide use in qemu.
One thing to note about the QEMU extension is that it specifies that the keycodes used are based on the XT scancodes. This does not seem to be entirely correct though as XT only had 84 keys and would therefore lack a lot of keys present on existing keyboard. In truth, it rather seems that it is based on AT Set 1, which is the XT scancodes plus AT like extensions to get full coverage. This assumption is based on looking at gtk-vnc's implementation.
We probably also need to look at bug 400 to get this working smoothly.
HTML clients need to be considered given their varying handling of keyboards.
noVNC now does this if the browser and server supports it. There is no setting to disable it. They are using the QEMU extension.
An interesting data point is that Microsoft extended the RDP protocol to send symbols instead of physical keys: https://msdn.microsoft.com/en-us/library/cc240585.aspx (TS_UNICODE_KEYBOARD_EVENT) Might have been to be able to support clients with virtual keyboards?
Implemented upstream now: https://github.com/TigerVNC/tigervnc/pull/513 Disabled by default though, so we can still decide how we want ThinLinc to behave.
