Bugzilla – Bug 4560
send physical keys instead of symbols
Last modified: 2018-08-27 14:31:07
You need to
before you can comment on or make changes to this bug.
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
- 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
- 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:
Might have been to be able to support clients with virtual keyboards?
Implemented upstream now:
Disabled by default though, so we can still decide how we want ThinLinc to