(some client side channels and all server side channels still need to be
ported to new api)
server: build fix, do not disable threads for rfx encoder
cliprdr client channel: implemented support for DisableThreads option
looks like thread does not make sense at all for this channel
do not initialize disabled image codecs (respect settings)
channels: client: rail: added support for DisableThreads setting
changed "BOOL DisableThreads" to "UINT32 ThreadingFlags"
dropped unnecessary apu changes
draft implementation of threading settings aware message handling api
for addins/channels
rail: use new messaging api
fixed memory leak
msgs handlers external api changes (as requested)
msgs_handlers: init fix
fixed memory leak
logic fix
resolved problems appeared after rebase to master, dropped unnecessary
changes
git clang-format origin/master
fixed TestFreeRDPCodecRemoteFX.c
"formatting, run `clang-format` please"
properly use new "rfx_context_new(BOOL, UINT32)" everywhere
passed Threading Flags to "rfx_context_new" where available
in older C standarts veriables declaration must be done before any code
requested changes
clang-format as requested
use broken signatures of standert C functions for m$ s**tos
clang-format
requested changes
requested changes
moved ThreadingFlags to stable api zone
define type for channel msg handler
typo fix
clang-format
build fix
us ThreadingFlags from server settings
git clang-format origin/master
clang-format
This fixes click and drag or more generally any press-hold-release combinations
for the primary mouse button.
Without this, click and drag, drag and drop and in, some remote applications
that presumably rely on the full press-release sequence, even button
presses don't always work.
For the negative scrolling direction, RDP uses the two's complement,
instead of the positive wheel value with the negative flag.
xfreerdp currently uses the positive wheel value in addition to the
negative flag, which results in a wrong wheel value on the server side
(136 instead of 120).
Fix this, by using the correct wheel rotation value, which is in the
two's complement.
Changed the logic of the disp channel to wait for 800ms after a
ConfigureNotify before sending the new resolution.
The problem fixed with this patch is the following:
1. Resize the window with the mouse
2. ConfigureNotify triggers a resize notification
3. The server resizes to the desired resolution
3a. More ConfigureNotify events are generated
4. The local window resize to the new resolution triggers another
ConfigureNotify
a. Depending on the timing (sending is already rate limited) the
events from 3a and 4 will make the size of the window jump
b. Very fast resizing will pick a random resolution from the
sequence of ConfigureNotify events as the final resolution
