(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
the discrete axis event gives changes in steps just like the
xfreerdp version uses. This way scrolling can be implemented
consistent with the behaviour of xfreerdp
* client: Fix exit codes for /help and similar option
Currently, non-zero exit code is returned for /version, /buildconfig, /help,
/monitor-list, /kbd-list and /kbd-lang-list command-line options for several
clients. This is against conventions because 0 is usually returned in
such cases. Also, there is potentially another problem that the returned
codes overflow on UNIX systems (where the exit code is a number between 0
and 255). Let's fix the clients to return 0 in the mentioned cases to honor
conventions and 1 for the command-line parsing errors (or -1 for clients
who already use that value).
Fixes: https://github.com/FreeRDP/FreeRDP/issues/6686
* Refactored freerdp_client_settings_command_line_status_print_ex
Now returns 0 if help or version information was requested.
* Do not eliminate original error status.
Co-authored-by: akallabeth <akallabeth@posteo.net>
I personally find it more convenient to have pasted data written to
the X11 PRIMARY selection, so that I can paste it with a fast middle-
button click, than to write to CLIPBOARD which typically needs a key
sequence or menu action.
This commit adds a command-line option to let me express that
preference: now I can say "/clipboard:use-selection:PRIMARY" on the
command line, which not only enables clipboard transfer but also says
which X selection I want it to talk to. The previous options
"+clipboard" and "-clipboard" are also still supported.
Now you can give an option the combination of flags
COMMAND_LINE_VALUE_OPTIONAL and COMMAND_LINE_VALUE_BOOL. If you do,
then all three of the syntaxes +foo, -foo and /foo:value are allowed
at once, and the receiving code can tell the difference because the
Value field is set to BoolValueTrue, BoolValueFalse or a valid char
pointer.
A selection owner is supposed to respond to a request for the
selection target TIMESTAMP by providing the X server time at which the
selection was written. There was a /* TODO */ comment in xf_cliprdr
where the code to do that should have been.
The absence of this can cause a problem when pasting into some X
clients. xtightvncviewer, in particular, will give up the attempt to
read from the clipboard at all if it doesn't get a satisfactory
response to the initial TIMESTAMP request - and the non-answer zero
value "CurrentTime" counts as unsatisfactory. It won't be happy with
anything short of a real X server time value.
(Checking the VNC source code, that's because it reads both PRIMARY
and CLIPBOARD and picks the one with the later timestamp. So it does
depend on the timestamps existing.)
When you're writing to the selection in response to a normal X event
like a mouse click or keyboard action, you get the selection timestamp
by copying the time field out of that X event. Here, we're doing it on
our own initiative, so we have to _request_ the X server time. There
isn't a GetServerTime request in the X protocol, so I work around it
by setting a property on our own window, and waiting for a
PropertyNotify event to come back telling me it's been done - which
will have a timestamp we can use.
* The display resolution change message was prone to a race condition
* Check for actual fullscreen state instead of settings
* Assume 75dpi for display resolution to mm conversion
mstsc will only load our gateway settings if gatewayprofileusagemethod
is set to 1. Otherwise it will always set the option "Auto-detect RD
Gateway server settings" and ignore the other gateway settings in the
rdp file.
This PR fixes various issues in the rdp file parser:
- NetworkAutoDetect was written inverted
- GatewayHostname was missing the port info (if not default)
- Several settings were left out when populating the file struct
The functions mappedGeometryRef and mappedGeometryUnref are API
functions ([1]) but were implemented in the geometry channel.
In case FreeRDP was built with BUILTIN_CHANNELS=OFF those functions
weren't available globally but used by the video channel.
Now the functions are fixed part of the freerdp-client library and
therefore available for all channels.
[1] exported in freerdp/client/geometry.h
Fixes#6236
This fixes the following defects reported by covscan tool:
- client/Wayland/wlf_input.c:251: overrun-local: Overrunning array "contacts" of 10 32-byte elements at element index 10 (byte offset 351) using index "i" (which evaluates to 10).
- client/Wayland/wlf_input.c:308: overrun-local: Overrunning array "contacts" of 10 32-byte elements at element index 10 (byte offset 351) using index "i" (which evaluates to 10).
- client/Wayland/wlf_input.c:360: overrun-local: Overrunning array "contacts" of 10 32-byte elements at element index 10 (byte offset 351) using index "i" (which evaluates to 10).
- client/Wayland/wlf_input.c:251: error[arrayIndexOutOfBounds]: Array 'contacts[10]' accessed at index 10, which is out of bounds.
- client/Wayland/wlf_input.c:308: error[arrayIndexOutOfBounds]: Array 'contacts[10]' accessed at index 10, which is out of bounds.
- client/Wayland/wlf_input.c:360: error[arrayIndexOutOfBounds]: Array 'contacts[10]' accessed at index 10, which is out of bounds.
- client/Wayland/wlf_input.c:246: uninit_use_in_call: Using uninitialized value "y" when calling "wlf_scale_coordinates".
- client/Wayland/wlf_input.c:246: uninit_use_in_call: Using uninitialized value "x" when calling "wlf_scale_coordinates".
The maximal number of touches can be higher then 10, see:
https://wayland.freedesktop.org/libinput/doc/latest/touchpads.html
Let's increse the MAX_CONTACTS count and add checks to prevent usage of
uninitialized values.
Thanks to @yol and @SaschaWessel a bug in scroll step conversion
was uncovered. The RDP value ranges are inverted when scrolling
in negative direction.
In `wlf_cliprdr_server_format_data_request()` `ConvertToUnicode()` may return 0
while not allocating memory for `cdata` and not setting `cdata` to a valid
address. In this case, `data` points to a random address.
Settting `cdata` to NULL before calling `ConvertToUnicode()` fixes this issues.
It is now possible to add usb devices both via vid+pid and via bus+addr
at the same time. To do this, the ids are directly
given to the corresponding command line options:
/usb🆔<vid+pids>,addr:<bus+addrs>
The dev option still works like before: /usb:id,dev:<vid+pids> or
/usb:addr,dev:<bus+addrs>
In case xf_OutputExpose is called with GFX or async-update a race
condition occured in combination with dynamic-resolution.
To prevent the deadlock update the screen on a best effort basis.
On high latency links the default of 9 second timeout might be too
strict. Adjusting this for all users will result in a long time
for connections to fail, so let these with high latency links
adjust the value manually.
* The mess with /cert-tofu, /cert-ignore et al is now unified in
a single option.
* Added the option to add fingerprint:<hash>:<hex string> multiple
times to /cert to build a list of accepted certificate
fingerprints
* Added a deprecation warning to older /cert-* options
