THe function xrdp_sec_in_mcs_data() parses data within the
TS_UD_CS_CORE struct which could just as easily be parsed
when xrdp_sec_process_mcs_data_CS_CORE() is called.
Currently the contents of the MSC Connect Initial PDU are stored within
the client_mcs_data member of the xrdp_sec struct. This stream is parsed
once by xrdp_sec_process_mcs_data() and then separately by
xrdp_sec_in_mcs_data(). There is no reason not to perform the parse in
a single pass through the stream.
This commit folds the functionality in xrdp_sec_in_mcs_data() into
xrdp_sec_process_mcs_data_CS_CORE() and removes xrdp_sec_in_mcs_data()
We always now indicate we support skipping channel joins. If the client
indicates this too, expect no channel join requests from the client.
If we do get some, process them anyway.
The existing code contains separate TLS and non-TLS code paths for
hadling channel join PDUs. This was introduced in
8fdc1ba216 and was based on a
misunderstanding of where in the connection sequence the TLS client hello
is processed (if a TLS connection is negotiated). The assumption was
the TLS client hello is received after the channel join PDUs. However,
it is actually received immediately after the X.224 Connection Confirm
PDU some time before channel join requests are processed.
Consequently, there is no reason not to adopt a single code path for
handling channel joins.
This is a regression introduced in v0.10.x
This version introduced a state machine to handle resizes requested
by the client and the server. Most configurations support resizeable
sessions, but one that doesn't is xrdp connecting to x11vnc on (e.g.) a
Raspberry PI.
If the session size requested by a client is differnt from the x11vnc
size, an error is logged and the state machine fails to complete,
resulting in a black screen.
This PR handles the problem by queueing a resize to the supported
server size and then continuing with the state machine. It's not an
optimal solution, but involves the least change to v0.10.x code.
Version 2.14.0 of cppcheck generates errors relating to the
check level (e.g.):-
common/base64.c:0:0: information: Limiting analysis of branches. Use --check-level=exhaustive to analyze all branches. [normalCheckLevelMaxBranches]
This does not happen with the same sources (commit
f781962a55) under 2.13.0.
This PR disables the warnings above for 2.14.0, but also allows a '-f'
argument to be passed in to request an exhaustive test. This could be used
(for example) before a major release. An exhaustive test takes a *lot*
longer. The first run with a git runner was around an hour.
The --check-level=flag was only added for 2.11.0, and so this now needs
a version check.
- Fix CI errors
- tconfig_load_gfx() removes H.264 from the supported codec list
if significant errors are found loading the H.264 configuration
- tconfig_load_gfx() always produces a usable config, even if the
specified file can't be loaded
When a connection is made to a system with the client numlock pressed, a
TS_SYNC_EVENT is sent before the module is loaded. This TS_SYNC_EVENT
correctly contains the NumLock status as 'pressed'. The event is, however,
discarded as the module isn't loaded.
When the module is loaded, a TS_SYNC_EVENT is not sent again unless
client focus is removed from the xrdp window and re-applied. As a
result, the NumLock state is incorrect unless this is done.
This commit stores the last TS_SYNC_EVENT sent before a module is
loaded. When the module is loaded, the sync state can be correctly
communicated to the module.
This commit allows a keycode_set to be specified as a module parameter
in xrdp.ini. This has the following effects:-
1) xrdp loads the specified keycode set for mapping RDP scancodes to
X11 keycodes. These are then passed to xorgxrdp as part of key press/
key release events.
2) The name of the XKB rules which use the specified keycode set are
passed to xorgxrdp so that XKB can be configured with rules which
match the chosen keycodes.
The effect is to remove all keycode set dependencies from xorgxrdp.
Normally evdev rules and evdev keycodes will be used but base rules and
base keycodes can be used instead for applications that require them.
Also, any systems which do not ship the evdev rules can be made to
work with base rules.
