The dynamic channel handler in xrdp_channel.c is updated to allow
the procs `data_first` pointer to be NULL. If this is done, the
channel handler performs all the dechunking necessary for the channel,
and only complete data PDUs are passed to procs 'data' callback.
This facility is applied to the dynamic channels supported by xrdp_mm.c.
The incoming callbacks for these channels now provide complete support
for the specification in [MS-RDPEDYC]. The existing channels were
incomplete in these respects:
1) The "Microsoft::Windows::RDS::Graphics" channel handler did not
support incoming PDUs between 1591 and 1600 bytes. The specification
calls for these to be sent as a single DATA_FIRST PDU.
2) The "Microsoft::Windows::RDS::DisplayControl" channel handler did
not support incoming PDUs over 1590 bytes.
The channel processor in xrdp_channel.c for dynamic streams uses
a data pointer and a length for passing PDUs or PDU fragments. We
replace this with a standard stream pointer, so that the usual
facilities can be used for checking length violcations.
The first argument to libxrdp_init() is a intptr_t / tbus value. This
represents the xrdp instance which is using the library, but this value
is always a 'struct xrdp_process' pointer.
This PR replaces the intptr_t with an incomplete type declaration at
the interface between xrdp and libxrdp.
The original intention was probably to provide some separation from
xrdp and the libxrdp code, but in practice this has turned out not to be
useful.
void * pointers in xrdp_session are replaced with pointers to
incomplete types. This allows us to remove a very large number of casts
related to these members in libxrdp.c
This allows sesexec to send a reason for a connection close
request to xrdp.
xrdp is also updated to support server initiated disconnection sequences
from [MS-RDPBCGR] 1.3.1.4, along with reporting a reason to the client
for the disconnection.
The responsibility for starting the drdynvc channel is moved out of
libxrdp into the application. This will make it easier to allow the
application to check the channel is enabled before starting it.
To implement a scalable login screen, we need to be able to ascertain
the DPI of the connected primary monitor.
At present, in a multi-monitor situation, this information is available in
the struct display_size_description, which can be searched for the primary
monitor. This is only the case however if the Display Control Channel
Extension is in use ([MS-RDPEDISP]), and a DISPLAYCONTROL_MONITOR_LAYOUT
has been received.
This PR retrieves physical monitor size information from the following
two additional places.
1) The TS_UD_CS_CORE PDU. Physical size information is optionally
included in this PDU for single-screen configurations.
2) The TS_UD_CS_MONITOR_EX PDU. This includes physical size
information for multiple-screen configurations.
- Eliminate duplicaiton for display_size_description
- monitorCount needs to be uint32_t
- width/height -> session_width/session_height
- Update CLIENT_INFO_CURRENT_VERSION
- Also some misc unit test updates.
- Minor log updates.
There are two places where monitor descriptions are passed through the
RDP protocol:
- TS_UD_CS_MONITOR ([MS-RDPBCGR] 2.2.1.3.6 Client Monitor Data)
- DISPLAYCONTROL_PDU_TYPE_MONITOR_LAYOUT ([MS-RDPEDISP] 2.2.2.2)
The processing logic for both of them is similar enough that they should be unified.
Also update to define the constants for the maximum and minimum desktop width/height for monitors and total area.
Also a large number of clarifications for the constants and protocol
requirements.
Note that this is also the first step to making resizing work with the extension GFX channel as well as an important
foundational step to enable HiDPI compatibility.
Also some misc logging updates.
remove not used chansrv <-> xrdp messages
move static channel disable control into libxrdp
remove some blocking read, write chansrv calls
add drdynvc calls to libxrdp
add drdynvc calls to chansrv
channel cleanup
matt335672