The values in @msdn{ms892480} seems to be what is used in TS_KEYBOARD_EVENT @msdn{cc240584}.
All the "XT Scan Code Translation Libraries" has been checked and integrated.
Only the Korean has been skipped. It is clearly something completely different
from everything else. The Japanese is just an extension of the US keyboard like
the others.
There is no 1:1 mapping between Virtual-Key codes and the "scancodes" used in
the rdp protocol. Some examples are VK_RETURN and VK_DIVIDE and US keyboards
where two different physical keys with different "scancodes" in the protocol
map to the same Virtual-Key on the server. Another bad fit seems to be the
Japanese backslash key.
The rdp scancodes are apparently undocumented and different from everything
else. The best we can do is to reverse engineer the protocol values and give
them some descriptive names and try to figure out how they relate to the native
scancodes on the supported platforms.
This also introduces a slightly more high-level convenience function for
sending key events. The existing function where an RDP protocol flag field has
to be encoded by the caller is very lowlevel ... and a bad fit for fastpath
input. That could use a refactoring.
