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.
As far as possible, use of the X11 display number is kept to
X11-specific routines. This is to make it easier to restructure
the code to add non-X11 display support.
the N policy in sesman.ini, allowing xrdp sessions to be tagged with an
instance name to enable persistent association with a specific
xrdp instance, to allow experiences where users reconnect to specific
sessions based on e.g. the xrdp listening port used.
This name better matches the name from [MS-RDPBCGR]. Also, the size
of the UTF-8 buffer allocated for the client name is not large
enough for some of the names which could potentially be passed across
in UTF-16 from the client.
The mapping from scancodes to the indexes used in xrdp_keymap
is not well designed and contains an implicit dependency on
keycode values.
This mapping is alse slightly different from the index used for
the 'keys' map in the xrdp_wm structure.
This commit introduces support for mapping scancodes directly
to 'scancode indexes' suitable for indexing into both structures.
Some renaming is also done; [MS-RDPBCGR] uses the terms scancode
and keyCode interchangeably. An effort is made to use key_code for a
raw value from a TS_KEYBOARD_EVENT, and scancode for a value which is
produced by the scancode module.
- Mostly base functions and utilities necessary to enable RFX
Progressive
- Add more EGFX work & mode flags.
- Update encoder.
- Does not yet include caps determination to enable RFX progressive
(yet).
- Update protocol constants
The connected client is currently described in two places in
the xrdp_client_info structure:-
1) In the connection_description field. This was introduced as
field client_ip by commit d797b2cf49
for xrdp v0.6.0
2) In the client_addr and client_port fields introduced by commit
25369460a1 for xrdp v0.8.0
This commit unifies these two sets of fields into a single
set of fields describing the connection IP and port (for
AF_INET/AF_INET6 connections only) and a connection description
for all connection types.
The code in os_calls to provide client logging has been simplified
somewhat which should make it easier to add new connection types (e.g.
AF_VSOCK).
The old connection_description field used to be passed to sesman to
inform sesman of the IP address of the client, and also to provide
a string for 'C' field session policy matching. 'C' field session policy
matching does not actually need this string (see #2239), and so now only
the IP field is passed to sesman.
* Added s_rem(s) for getting the remaining bytes in a stream
* Added s_rem_out() macro
* Fixed 15bpp pointer error checking
* Combined the 512 and 2048 bit certificate sending code paths
* Other detailed comments and logging added following MS-RDPBCGR
The MS specs determine that the character buffer lenngths
for usernames, domains, passwords, alternate shells, etc
can be up to 512 characters including the mandatory null
terminator.
Constants from MS documents (MS-RDPBCGR etc) moved out of
common/xrdp_constants.h into includes named after the documents.
Similar includes moved from sesman/chansrv to the common area.
classify constants into these 5 types
* constants for xrdp
* constants come from ITU-T Recommendations
* constants come from Remote Desktop Protocol
* constants come from other MS products
* unclassified yet
matt335672