Bug 4560 - Send physical keys instead of symbols
Summary: Send physical keys instead of symbols
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: MediumPrio
Assignee: Pierre Ossman
URL:
Keywords: upstream
Depends on:
Blocks: 3523
  Show dependency treegraph
 
Reported: 2013-03-20 10:22 CET by Pierre Ossman
Modified: 2020-02-04 12:55 CET (History)
0 users

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2013-03-20 10:22:59 CET
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.
Comment 1 Pierre Ossman cendio 2013-07-03 10:10:42 CEST
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.
Comment 2 Pierre Ossman cendio 2013-07-03 10:11:31 CEST
We probably also need to look at bug 400 to get this working smoothly.
Comment 3 Pierre Ossman cendio 2013-10-23 14:56:52 CEST
HTML clients need to be considered given their varying handling of keyboards.
Comment 4 Pierre Ossman cendio 2016-09-05 14:31:33 CEST
noVNC now does this if the browser and server supports it. There is no setting to disable it. They are using the QEMU extension.
Comment 5 Pierre Ossman cendio 2017-07-14 10:21:41 CEST
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?
Comment 6 Pierre Ossman cendio 2018-08-27 14:31:07 CEST
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.

Note You need to log in before you can comment on or make changes to this bug.