* Fixed remdesk settings pointer
* Fixed sign warnings in display_write_monitor_layout_pdu
* Use freerdp_abort_connect_context and freerdp_shall_disconnect_context
* Added and updates settings
* info assert/dynamic timezone
* mcs assert/log/flags
* Fixed and added assertions for wStream
* Unified stream length checks
* Added new function to check for lenght and log
* Replace all usages with this new function
* Cleaned up PER, added parser logging
* Cleaned up BER, added parser logging
* log messages
* Modified Stream_CheckAndLogRequiredLengthEx
* Allow custom format and options
* Add Stream_CheckAndLogRequiredLengthExVa for prepared va_list
* Improved Stream_CheckAndLogRequiredLength
* Now have log level adjustable
* Added function equivalents for existing logger
* Added a backtrace in case of a failure is detected
* Fixed public API input checks
When a FormatDataRequest by xfreerdp is answered with the
CB_RESPONSE_FAIL flag, then the request was answered, but xfreerdp does
not mark it as answered, by leaving the request as pending.
This results in non-functional copy-paste actions, when copying
something from the server side, after the failed request.
A similar situation can happen, when a new FormatList is received,
while there is a pending FormatDataRequest.
Fix these situations by clearing the pending request, when a form of an
answer, either via CB_RESPONSE_FAIL flag or via new FormatList, is
received.
Fixes: https://github.com/FreeRDP/FreeRDP/issues/7757
* Prefer xinput events over x11 events for mouse input
* Prefer xinput raw events over xinput events:
* Only use when the mouse is grabbed (events are not bound to a
specific window but are global)
* Only use for relative mouse input
When leaving fullscreen with enabled smart sizing the window size
did shrink due to first resizing the window, then enabling window
decorations and finally moving to the correct position.
Covscan report contains various memory leak defects which were marked
as important. I have spent some time analyzing them and although they
were marked as important, most of them are in error cases, so probably
nothing serious. Let's fix most of them anyway. The rest are false
positives, or too complicated to fix, or already fixed in master, or
simply I am unsure about them.
Relates: https://github.com/FreeRDP/FreeRDP/issues/6981
(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
* 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
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.
Since the EGFX Reset Graphics PDU seems to be optional,
the graphicsReset variable (which is updated in that PDU's handler)
should be removed from the rdp_gdi struct with the next change
in public headers (as in freerdp v3).
There are still some clients that expect and check it and therefore
we keep it for now, initialized with TRUE.
sdas
XOpenDevice() may fail and return NULL, so try to find the first
pointer device that can be opened, and ensure that ptr_dev argument
is not NULL before passing it to XGetDeviceButtonMapping().
According to the channel docs, this field is only used in format data
request. Therefore, there's no need to hold it in the response. cliprdr
server code was copy-pasted from client code, therefore this must be
some leftover.
Clipboard formats containing plain text are specified to be terminated
by a \0 character in MS's documentation on standard clipboard formats:
https://docs.microsoft.com/en-us/windows/desktop/dataxchg/standard-clipboard-formats
xf_cliprdr_server_format_data_response receives pasted data from the
server to transfer to the client, in a sufficiently raw form that the
\0 terminator is still present, so it has to remove it. It does so by
checking only at the very end of the data. But I've observed that when
pasting out of at least one Windows program (namely Outlook 1903 on
Windows 10), the intended paste data arrives in this function followed
by \0 and then a spurious \n. In that situation the null-terminator
removal will fail to notice the \0, and will leave both bogus
characters on the end of the paste.
Fixed by using memchr to find the _first_ \0 in the paste data, which
should not lose any actually intentional data because it's in
accordance with the spec above.
The file clipboard delegate needs a base URI to operate on for
systems that are not WIN32. Added that to the context and abort
conversion, if that is not set. (currently not fully implemented)
[client/X11/xf_floatbar.c:800] -> [client/X11/xf_floatbar.c:796]: (warning) Either the condition '!floatbar' is redundant or there is possible null pointer dereference: floatbar.
[client/X11/xf_floatbar.c:800] -> [client/X11/xf_floatbar.c:797]: (warning) Either the condition '!floatbar' is redundant or there is possible null pointer dereference: floatbar.
[client/X11/xf_floatbar.c:800] -> [client/X11/xf_floatbar.c:798]: (warning) Either the condition '!floatbar' is redundant or there is possible null pointer dereference: floatbar.
[libfreerdp/codec/dsp.c:1156] -> [libfreerdp/codec/dsp.c:1154]: (warning) Either the condition '!srcFormat' is redundant or there is possible null pointer dereference: srcFormat.
[channels/drdynvc/client/drdynvc_main.c:1453] -> [channels/drdynvc/client/drdynvc_main.c:1450]: (warning) Either the condition '!drdynvc' is redundant or there is possible null pointer dereference: drdynvc.
[channels/audin/client/opensles/audin_opensl_es.c:98] -> [channels/audin/client/opensles/audin_opensl_es.c:94]: (warning) Either the condition '!opensles' is redundant or there is possible null pointer dereference: opensles.
[channels/audin/client/opensles/audin_opensl_es.c:159] -> [channels/audin/client/opensles/audin_opensl_es.c:153]: (warning) Either the condition '!opensles' is redundant or there is possible null pointer dereference: opensles.
Up until now X11 mouse button remapping was only possible for the
default buttons 1 to 3.
With this pull any X11 mouse button can be mapped to any RDP mouse
event and all X11 remappings are respected.
The cause is very simple: we didn't map the xwindow on receiving
WINDOW_SHOW. but doing that causes another problem that you can't
hide a window anymore, and that is because whlie window hiding, the
_NET_WM_STATE and WM_STATE properies of the xwindow may change, in
the function `xf_event_PropertyNotify` we just assume that windows
not maximized, not minimized, yet not showing normally should be
corrected to be shown, we just need to consider the situation that
the window is hidden here.
fix: #5078
The extended information provided by VerifyCertificateEx and
VerifyChangedCertificateEx is now exploited by the new functions
client_cli_verify_certificate_ex and client_cli_verify_changed_certificate_ex.
The old callbacks now print out deprecation warnings to inform the
user and developer about this deprecation.
To fix#4825 GFX functions must now aquire a lock before accessing surfaces.
This prevents simultaneous update of internal data by client and gfx threads.
Also enforce return value checks, where not already done.
Added a library internal function freerdp_settings_set_default_order_support
which initializes the OrderSupport array of settings.
Now clients no longer need to set this up on their own, if they
do not implement their own hardware accelerated order processing.
With #4950 client side pointer implementation was made optional.
This addresses an issue that each client had to call
pointer_cache_register_callbacks on its own.
Icons on X11 windows are configured using the _NET_WM_ICON property
described in Extended Window Manager Hints. Here we implement converison
from DIB bitmaps used by RAIL to the format expected by _NET_WM_ICON,
and actually set the icon for RAIL app windows.
Both DIB format and _NET_WM_ICON (or rather, Xlib) are weird. Let's
start with RAIL's format. That's the one used in BMP and ICO formats
on Windows. It has some strange properties but thankfully FreeRDP's
freerdp_image_copy() can handle most of them for us. (With an exception
of monochrome and 16-color formats that it does not support. Sorry, but
I'm too lazy to fix them. They are not seem to be used by any real
application either.) The one thing that it can't do is to apply the
alpha transparency bitmask so we have to do it manually. This instantly
reminds us that DIB format has HISTORY: it's vertically flipped and
each must be padded to 4 bytes. Both these quirks having reasonable
(for a certain definition of 'reason') explanations. Such is life.
(Also, 8-bit images require a color palette which we must fill in.)
So okay, now comes _NET_WM_ICON. It is more sane (or rather, easier to
deal with). The bitmap is represented with a tiny [width, height] header
followed by an array of pixels in ARGB format. There is no padding, no
weird color formats. But here's a catch: you can't simply take the
output of freerdp_image_copy() and cast to (unsigned char*) of colors.
We have to allocate an array of C's longs and copy the pixels there,
because that's what Xlib expects (and this is mentioned in the spec).
Simply casting an array of bytes causes crashes on 64-bit systems.
So don't try to cheat or "optimize" and read the docs, kids.
Note that XFlush() call after XChangeProperty(). It's there because it
seems to helps see the icon quicker with Unity on Ubuntu 14.04. I don't
know why. (And Unity does not support _NET_WM_ICON officially. But it
sorta kinda works sometimes.)
Oh, and while we're here, delete some old, unused, and commented out
code that was setting window icons in the past. It's not needed anymore.
This commit adds a cache for RAIL application icons. It is (surpisingly)
used to cache icons for remote applications. This mechanism is described
in MS-RDPERP 3.1.1.2 Icon Cache Support and related items.
Note that some (actually, most) of the icons are not cached. These are
marked with CacheId == 0xFF. In order to keep the code clean we do not
introduce a special case and instead use a 'scratch' icon and simply
pretend to return an xfRailIcon from cache.
We're going to set icons via _NET_WM_ICON property which explains
why we use "long" values to store pixel data. The icon conversion
is not implemented in this commit, it's only stubs.
However, we do implement processing of window information orders that
contain new icons or cached references to previously sent icons. Note
that it is important to not fail (i.e., to not return FALSE) if we
cannot find a window for the icon by its ID. The server occasionally
likes to be slow or something and send icon updates for nonexistent
windows. This behavior is mandated by the spec, too:
MS-RDPERP 3.2.5.1.6 Processing Window Information Orders
Upon receipt of a Window Information Order for an icon or
cached icon, as specified in sections 2.2.1.3.1.2.2 and
2.2.1.3.1.2.3, the client SHOULD locate the local RAIL window
that corresponds to the WindowId reported in the Hdr field
and apply the icon updates to the RAIL window. If no such
window can be found, the client SHOULD ignore the order.
Indeed, we silently ignore such orders now.
