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.
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.
The Brazilian ABNT2 Keyboard layout contains a keypad
decimal key which doesn't exist on other keypads:-
https://www.kbdlayout.info/kbdbr/virtualkeys
This key is curently mapped in xorgxrdp to keycode 134 (basic mapping),
but isn't present in the scancode map. It needs to be added so that it
is available to VNC sessions and will be mapped for xorgxrdp when we
move to evdev keycode mappings.
Replace definitions in ms-rdpbcgr.h marked as TODO with the
names defined in [MS-RDPBCGR]
Some other simplifications around the fake Unicode event processing
have also been made.
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.
This commit changes the license response PDU to be constructed rather
than simply being contained as a binary blob.
Some constants in common/ms-rdpbcgr.h are renamed with the values
from the specification.
If xrdp is running with dropped privileges it won't be able to delete
the PID file it's created. Places where xrdp is stopped need to cater
for this.
It's prefereable to do this than make the PID file writeable by xrdp
with dropped privileges, as this can still lead to DoS attacks if an
attacker manages to modify the PID file from a compromised xrdp
process.
- xrdp_listen.c is refactored so we can create the
listening socket(s) before dropping privileges.
- The code which reads startup params from xrdp.ini
is moved from xrdp_listen.c to xrdp.c, so it
is only called once if we test the listen before
starting the daemon.
If ./configure is used with devel logging, but without --enable-pixman,
the stub pixman development files are used.
However, in this configuration, the pixman_region_selfcheck() function
is declared, but not defined.
This is a regression introduced in 7e58209b19
- xrdp is not now built with XRDP_IBUS to allow other input
methods to be more easily supported.
- chansrv is only aked to start an input method if the client
supports it.
- chansrv sends a status report back to xrdp when asked to start
and input method.
- ./configure without --enable-ibus now works.
When xrdp is built with IPv6 support it will only fall back to IPv4 if
IPv6 is not supported (EAFNOSUPPORT). However, if the system is IPv6
capable but doesn't have an IPv6 address set (at least inside a FreeBSD
jail) EPROTONOSUPPORT is returned from socket().
The '-lrt' added to the Makefile for the common library appears
to be unnecessary.
- On modern Linuxes, this library has been merged with libc, and the
supplied library is empty.
- On older ones (e.g. Devuan 4), the library contains routines we
do not use in xrdp (although we use 'shm_open()' in xorgxrdp).
- On FreeBSD 14 the library contains only mq_* and timer_* routines
which, again, are not required.
From [MS-RCPBCGR] 3.3.5.12.1:-
> ...The contents of this PDU SHOULD NOT be compressed.
>
> This PDU MUST NOT be sent to a client that has not indicated support for
> it by setting the RNS_UD_CS_SUPPORT_MONITOR_LAYOUT_PDU flag (0x0040)
> in the earlyCapabilityFlags field of the Client Core Data (section
> 2.2.1.3.2).
Also, 2.2.12.1 specifies the source channel must be zero.
In testing, a compressed monitor layout PDU causes mstsc.exe
to exit with a protocol error.
* Store EGFX state before entering resize state machine
At present the EGFX state is destroyed by states WMRZ_EGFX_DELETE_SURFACE
through WRMZ_EGFX_DELETE. This means that at WMRZ_EGFX_INITIALIZE we
cannot distinguish between EGFX not being ever used, and EGFX
having been torn down. Consequently, when running non-GFX, we don't
correctly recover the session.
* Allow multiple reasons for suppress_output
Replaces the single boolean for suppress_output with
a bitmask, to allow output to be suppressed for
more than one reason
* Disable output during resize
* Add states to dynamic resize
Adds states to the dynamic resize state machine so we wait for a
Deactivation-Reactivation sequence to finish before sending pointer
updates, etc.
* suppress module output during the dynamic resize
* Add support for dynamic resize to VNC backend
xrdp_mm needs to be informed when a resize has been performed so that
the resize stte machine can be updsate.
Since v0.9.9, xrdp has assumed that the "drdynvc" static virtual
channel is available for its exclusive use. With GFX support, it
is necessary to codify this to prevent this sequence of operations:-
- NeutrinoRDP target sends DVC Capabilities Request PDU
- target responds wih DVC Capabilities Response PDU
- xrdp processes this, starting the GFX virtual channel again
In the future, if NeutrinoRDP requires access to virtual channels,
data may somehow need to be passed through to the target while being
parsed and handled appropriately within xrdp.
* GFX: sort versions, flags to return the highest version we support in caps advertise
* GFX: simpify swtich in caps_advertise
* GFX: log skipped capability versions in caps_advertise
- 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
On Linux, the TCP send buffer size is increased to 32768 if it is less
that this (which it normally is). This however has the effect of disabling
dynamic buffer sizing, leading to a maximum available bandwidth of
max_bandwidth = 262144 (bits) / round_trip_time (secs)
This is not noticeable on a LAN with an RTT of around 0.5ms, but
very noticeable on a WAN with an RTT of 0.25s.
Comments in the config file and manpage in this area are improved, as
is the logging if the parameters are actually set.
- Use clearenv() if it exists
- Don't rely on <limits.h> being pulled in by <sys/param.h>
- Rename the DEFAULT_TYPE macro in sesrun.c. This name appears to be
used on Solaris. It's not a good choice.
Some clients appears to be sending cbClientAddress and/or cbClientDir
as 0 in the TS_EXTENDED_INFO_PACKET. This appears to be at odds with
[MS-RDPBCGR] which requires mandatory terminators for these fields.
The top level socket directory is now called XRDP_SOCKET_ROOT_PATH.
Below that are user-specific directories referred to with the
XRDP_SOCKET_PATH macro - this name is hard-coded into xorgxrdp and
the audio modules as an environment variable.
XRDP_SOCKET_PATH now looks like $XRDP_SOCKET_ROOT_PATH/<uid>
XRDP_SOCKET_PATH is only writeable by the user, and readable by the user
and the xrdp process.
