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.
xrdp_load_keyboard_layout() is used exclusively by the xup module to
work out the parameters to pass to xorgxrdp for XKB. This function
does not need to be called locally from the SEC module.
This commit moves the function to xrdp/lang.c and renames it as
xrdp_init_xkb_layout(). The module interface is modified so that xup can
call this function. Other modules do not need to call it.
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.
matt335672