dynamic channels can be opened at any time during a session. If we
receive a CREATE_REQUEST_PDU and the channel id is already in use, print
out a warning with the existing channel details and discard it before
creating the newly requested channel.
Implement a (optional) peer limitation check for shadow server.
with the command line option /max-connections:<number> the maximum
number of simultaneous connections can be limited.
The current server side channel handling of AUDIO_INPUT is currently
very constrained:
- Server implementations cannot measure the clients uplink, since the
Incoming Data PDU is currently unhandled and FreeRDPs DSP handling
delays the callback call of ReceiveSamples
- Servers currently cannot prefer a different protocol version
- Servers currently cannot change the used format
To solve these issues without running into the risk that some
simplifications constraint certain API usage, rework the current channel
handling to be very close to the documentation.
This means, that all documented API calls can be made by server
implementations and all documented PDUs, that the server side is
expected to receive are just parsed inside FreeRDP and then forwarded to
the API implementation.
* Use new enum constants with WINPR_KEYBOARD_* prefix
* Fix mapping of keycodes and scancodes, the offset of 8 is no longer
required if the proper keyboard type is used.
CertificateContent and PrivateKeyContent now have two valid formats:
It can be in format PEM (multiple lines) or a single line base64 encoded
PEM.
The first format is preferrable in case the pf_config* API is used to
set the certificate/key, the latter in case an actual config file is in
use where multiline configuration data can not be directly entered.
* 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.
The decoded base64 data might contain PEM with/without/with multiple
'\0' at the end of the string. We do not want to drag this through our
code so ensure the length matches the string length including '\0'
