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'
The attributes xPos and yPos for a Color Pointer Update are confusing,
as they may be confused with the xPos and yPos of the pointer bitmap on
the actual screen.
Rename these attributes to what they actually represent, and that is the
hotspot position.
xPos and yPos are still members of the hotspot. However, hotSpotX and
hotSpotY are much more clearer.
In addition to that, the Large Pointer Update uses the same names for
the hotspot coordinates.
akallabeth