As KEYCODE_TYPE_XKB is 3, in the previous code we were doing some "and masking"
and so when calling GetKeycodeFromVirtualKeyCode(code, KEYCODE_TYPE_XKB), the
function was always interpreting the virtual key code with the apple layout.
This patch fixes that and also mutualize the search in the code array.
* move type definition to WinPR as used there too.
* supported keyboard types are defined in
[MS-RDPBCGR] 2.2.1.3.2 Client Core Data (TS_UD_CS_CORE)]
use a enum instead of magic numbers to make code more readable.
WinPR provides APIs to convert between keycodes between virtual
keycodes.
These keycodes can currently be evdev keycodes or Apple keycodes.
The evdev handling, however, handles XKB keycodes and not evdev ones.
The main difference between these is that XKB keycodes are shifted by
the value 8, compared to evdev keycodes.
In order to fix this situation, rename the evdev keycodes to XKB ones,
and introduce additionally a new keycode evdev, including its handling
for this keycode type.
* Fixed GetFileInformationByHandle initializers
* Fix#7793: Do not expose internal input API
Slow-Path input uses UINT16 for scancodes on wire, but only the
lower byte is actually used. (the extended fields are sent in
keyboardFlags field)
Hide this implementation detail and adjust the API to use UINT8
for the code instead just like the corresponding Fast-Path PDU
* Added a warning for problematic slow path keyCodes
winpr is now always build as single library.
The build option MONOLITHIC_BUILD doesn't influence this behavior anymore.
The only exception is winpr-makecert-tool which is still build as extra
library.
This obsoletes complex_libraries for winpr.
