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.
The async transport option is broken by design.
If used the main loop is called from the transport thread and the
main thread of the application.
Unless the transport layer is refactored to just work on queues
(input and output) this option will never work, therefore remove it.
Add code annotation to silence false positive warnings from covscan
due to omitting termination \0.
buffer_size: Calling strncpy with a source string whose length (13 chars) is greater than or equal to the size argument (13) will fail to null-terminate "&tmp[cs]".
Remember the callback state to avoid calling reerdp_channels_post_connect
before the corresponding client callback has benn called.
This might happen during redirection and reconnection.
1. Fix fullscreen toggle for window managers that do not have multimonitor fullscreen extension support
2. Fix current monitor detection
3. Fix calculation of vscreen boundaries when single monitor is being used
4. Fix start up position of window when starting (used to always go to the top left corener, now centered)
Still a problem:
1. Window decorations do not show when going windowed
2. Smart resizing makes i3 really sad :(
3. Moving window across monitors and going fullscreen always maximizes on startup screen (when not using /multimon)
X11 is asynchronous, so events arriving in xf_event_PropertyNotify
may access a window that has already been discarded. Check that before
reading properties.
issue detected by cppcheck
[channels/drive/client/drive_main.c:454] -> [channels/drive/client/drive_main.c:443]: (warning) Either the condition '!irp' is redundant or there is possible null pointer dereference: irp.
[client/X11/xf_window.c:582] -> [client/X11/xf_window.c:580]: (warning) Either the condition '!xfc' is redundant or there is possible null pointer dereference: xfc.
[winpr/libwinpr/path/test/TestPathShell.c:40] -> [winpr/libwinpr/path/test/TestPathShell.c:43]: (warning) Either the condition '!path' is redundant or there is possible null pointer dereference: path.
[winpr/libwinpr/path/test/TestPathShell.c:49] -> [winpr/libwinpr/path/test/TestPathShell.c:52]: (warning) Either the condition '!path' is redundant or there is possible null pointer dereference: path.
The generator tool is called by CMake and is incompatible
with certain options. Therefore this commit
* removes WinPR dependency
* removes -fsanitize=* from CFLAGS
Implements the decoding of video streams using common H264 decoders. We also implement
a trivial feedback algorithm.
Sponsored by: Rangee GmbH (http://www.rangee.de)
When using pthread_once with destructors they are only called,
if each thread (including the main thread) is exited with pthread_exit.
Introducing winpr_exit as a wrapper for that purpose.
Move the cmd struct to a extra header file. This allows it to only
include the header file in generate_argument_docbook.c and therefore
remove a linker dependencies.
Since ec027bf dynamic resolution is broken when used with egfx. Before that commit
we were tracking a server sent resize by setting a DesktopResize callback. This callback
is called when the desktop is resized by the server. Anyway the problem was that when this
callback is called, the activation sequence is not always completed, which were leading to
some freeze with 2012r2 servers (sending packets before the sequence is finished).
So with the faulty commit, we are tracking server resizes by subscribing to the Actived
event, that is called at the end of a reactivation sequence, so we're sure to not send packets
when not fully activated.
Anyway the issue that shows on (#4330) is that when you use egfx, no reactivation sequence happens,
the server only sends a ResetGraphics message with the new size, and so we miss the resized event.
This fix introduces a new GraphicsReset event, makes the display channel subscribe to that event,
and react accordingly.
Fix a too restrictive detection of XRandr support.
Set more monitor's attributes like physical size and orientation when XRandr is
available.
Set [desktop|device]ScaleFactor when it has been given on the command line, this
should fix#4324.
freerdp_disconnect must only be called, if the connection
was established. Otherwise all resources are cleaned up twice
leading to double free and other issues.
Some window managers do not support _NET_WM_FULLSCREEN_MONITORS.
In that case multimonitor fullscreen does not properly work, so
add a path resizing the window over all screens instead.
Based on @erbth pull request, adding proper X11 atom checks.
If the display channel is available we use it to allow the user to resize the
xfreerdp window. When the window is resized we announce a new monitor layout and
the server reacts by doing a reactivation sequence to the new size.
The minimum window size is limited to 300x300 as 2012 servers crash horribly
if we send them a smaller layout.
This patch contains several improvements:
- add missing colons before format strings
- always print format string after argument
- do not duplicate format string before description
- use <replaceable> only for variables in format string
- use +/- for boolean arguments
- print also default value for all kinds of arguments
If the size parameter is used with a percentages like /size:50% now
an additional 'w' or 'h' can be appended (like /size:50%w) to specify
where the percentage should be applied. If both or none are set the
behavior is like it was before and the percentage is applied to width
and height.
* client/x11: Fix colors on big endian
The bitmaps are recieved in little endian byte order (LSBFirst in terms
of X11). This is a problem on systems, where bitmaps are expected in big
endian byte order (MSBFirst). X11 client tries to handle this situation
by different color formats (e.g. RGBX vs. BGRX), but this doesn't work.
BGRX is not MSBFirst variant of RGBX, it should be XRGB. But this would
work only for 32/24 depths, where color channels matches bytes. Let's
say to the XServer that all the bitmaps are in LSBFirst encoding instead
of changing the color formats on big endian systems.
https://github.com/FreeRDP/FreeRDP/issues/2520
* client/x11: Fix cursor color on big endian
The cursor color is wrong on big endian systems. It is not probably
possible to force bitmap_order for XcursorImage as it is possible for
XImage. Fortunately, cursors are always 32 bit so we can use ABGR
instead of BGRA to deal with.
https://github.com/FreeRDP/FreeRDP/issues/2520
* client/x11: Fix comment indentation
The comment has wrong indentation for some reason, let's fix it.
* client/x11: Fix BGR vs. RGB detection
The BGR vs. RGB detection code is leftover from history and I am conviced
that it is wrong with the current color handling, where invert flag is TRUE
by default. However, I suppose that the detection still makes sense and
XServer may use the inverted formats in some cases. Maybe we can force XServer
to use our masks somehow, but let's just fix the value to FALSE now.
* client/x11: Remove unused color shifts
The color shifts are lefover from history and are not used in current
code. Let's remove them.
Arguments of xf_Bitmap_SetSurface are not checked before use currently
which may lead to segfaults. It may happen if bitmap is not found in a
cache from some reason. Let's check the arguments before use similarly
as it is done in client/Windows/wf_graphics.c in order to avoid segfaults.
https://github.com/FreeRDP/FreeRDP/issues/4117
xf_FixWindowCoordinates occasionally set the dimensions of the window to invalid values (0) because the minimum value check was done at the beginning of the method rather than at the end
With some usb barcode scanners, repeated characters do not appear in the freerdp session.
It looks like this is because the KeyRelease signal is not sent for the first character.
Removing this if check fixes the problem.
The data provided by local applications can be actually encoded in
UTF-16 (e.g., Firefox does this to HTML). UTF-16 allows embedded null
bytes so we should not use strlen() to fix up the data. The HTML format
synthesizer can handle trailing null bytes just fine and can detect
whether it deals with UTF-8 or UTF-16.
Most of the functions is this file are internal-use callbacks so they do
not need to be exported from the compilation unit. Mark functions static
as appropriate.
The H264 context is surface specific, so in multi-monitor (with multiple surfaces)
the decoding was failing. This patch fixes that by introducing a surface specific
h264 context.
XSelection protocol does not define any global clipboard as there is on
Windows. Instead each window has its own property for clipboard content
(like CLIPBOARD or PRIMARY) and there is a global notion of clipboard
ownership. Only one window can claim ownership of some clipboard type
at the moment.
FreeRDP uses CLIPBOARD for clipboard transfers (it's the one used by
applications when Ctrl+V is pressed). For regular desktop sessions the
session window itself is used for clipboard interactions via
xfc->drawable field. However, for remote app session there is no session
window. We cannot use the current remote app window as it may change or
be destroyed without closing the session. We also cannot use the root
window as it is already used for CF_RAW transfer protocol.
Therefore we create a simple dummy window to put into xfc->drawable for
this exact job: to act as a clipboard vessel on behalf of the entire
remote app session.
xf_create_window() usually creates the window as we immediately start in
RAIL mode when possible. xf_rail_enable_remoteapp_mode() is invoked only
when autologin failed or remote desktop had to show the session window
to the user for some reason.
The surface's damage region is not relative to the output but
lives in its own universe starting at origin 0,0.
Also fixed the drawing coordinates used in the XRENDER code path
which is used with /smart-sizing
Now that we've got everything in place to handle files it's time to tell
the server that we can actually do this.
MS-RDPECLIP 3.2.5.1.3 Sending a Client Clipboard Capabilities PDU asks
us politely to not advertise file clipping support if the server did not
do that itself. Thus we need to parse the capabilities sent by the
server and take a note whether it supports file clipping.
There is also no point in advertising file clipping support if
wClipboard failed to initalize any local file subsystem, in which case
we cannot handle files for real. Take a note of this as well when we
register the file formats.
If everthing is really in place and the stars shine upon us then we are
allowed to set CB_STREAM_FILECLIP_ENABLED in the capabilities. There is
no command line switch to disable file clipping (and there is little
reason to), so we always support it if we can.
We also set an additional flag CB_FILECLIP_NO_FILE_PATHS flag in the
capabilities because it seems to be necessary for the server to send the
"FileGroupDescriptorW" format to us. Otherwise the server will only send
the old CF_HDROP format which can't be handled well without enabled disk
drive redirection and a properly negotiated server-side temporary
directory.
xf_cliprdr_server_file_contents_request() handles the
CLIPRDR_FILECONTENTS_REQUEST which is sent by the server to retrieve the
size or data of a single file. The server can only request one of these
things at a time, do confirm this.
The actual handling of the requests is done by wClipboardDelegate. In
order to handle its resposes we register a bunch of our own callbacks
which simply pass the responses to the server.
In case of an error we should always send a CB_RESPONSE_FAIL to the
server. If we do not then the file transfer progress dialog may end up
hanging in the remote session forever until the user logs out or kills
explorer.exe. We do wnat this.
To handle a new format we should first be able to transform the format
name from the local clipboard owner into its remote representation. In
our case this will be trasforming the "text/uri-list" target into the
"FileGroupDescriptorW" named format.
Add CB_FORMAT_TEXTURILIST to identify the local format by its ID during
the data conversion step. This numeric ID has nothing to do with the ID
which will be sent to server. It's a bit weird, but that's how XFreeRDP
works.
After that add a new client format with this ID and appropriate local
and remote format names (in atom and formatName fields respectively).
Do this only if wClipboard actually supports "text/uri-list" format.
(It could fail to initialize the local file subsystem, in which case
it will fail all file-related requests and there would be no point in
advertising the file format support in the first place.)
Finally, handle the actual format data request for a new named format
in xf_cliprdr_process_requested_data(). Remember to convert the
FILEDESCRIPTOR array we receive from wClipboard into the
CLIPRDR_FILELIST expected by the server. Also take care to not leak
memory during this conversion.
Note that this handles only the CLIPRDR_FORMAT_DATA_REQUEST. The server
is still not able to retrieve the file content as this is done via a
separate request-reply sequence.
Unify error handling in xf_clipboard_new() by using a common cleanup
code path. This fixes a leak of clipboard->system and format names when
an error occurs during initialization.
Also reformat the code to fit into 100 column limit without this line
break insanity and with improved readability.
I do not particularly like to use a variable with such a descriptive
name 'n' far away in the error handling part, but its short name is
kinda important for readability so let's keep it as is.
- draw only the updated region in the gdi and x11 surface bits implementation
- don't repeatedly call IsProcessorFeaturePresentEx in rfx rlgr decoder
- fix ugly and unaligned profiler print layout and remove an unnecessary value
FreeRDP uses clipboard->data to cache the result of the Windows->X11
clipboard format conversion, and xf_cliprdr_process_selection_request()
immediately provides this result to local applications if they request
the same clipboard format again. This saves us a possibly costly
conversion in case where the user pastes data repeatedly.
However, this caching mechanism did not support raw clipboard transfers
where the unmodified data is passed between two FreeRDP clients. We use
the same XClipboard protocol for this, so the clipboard->data is in play.
We clear the cached value when we receive new data from the server, so
initially raw transfers are fine. But if some local application (e.g.,
a clipboard manager) asks for some data format before the data is pasted
into the second FreeRDP session then clipboard->data will contain the
*converted* data. And this converted cached data will be provided to
the second FreeRDP session as a part of the raw data transfer. Instead
we should have provided the original data.
In order to achieve this we are now caching the original data in the
same way as the converted one, and the original data is now correctly
provided when the second FreeRDP session asks for a raw data transfer.
[client/X11/xf_rail.c:205] -> [client/X11/xf_rail.c:220]: (warning) Either the condition 'if(appWindow)' is redundant or there is possible null pointer dereference: appWindow.
[client/X11/xf_rail.c:206] -> [client/X11/xf_rail.c:220]: (warning) Either the condition 'if(appWindow)' is redundant or there is possible null pointer dereference: appWindow.
[client/X11/xf_rail.c:207] -> [client/X11/xf_rail.c:220]: (warning) Either the condition 'if(appWindow)' is redundant or there is possible null pointer dereference: appWindow.
[client/X11/xf_rail.c:208] -> [client/X11/xf_rail.c:220]: (warning) Either the condition 'if(appWindow)' is redundant or there is possible null pointer dereference: appWindow.
[client/X11/xf_rail.c:215] -> [client/X11/xf_rail.c:220]: (warning) Either the condition 'if(appWindow)' is redundant or there is possible null pointer dereference: appWindow.
[client/X11/xf_rail.c:216] -> [client/X11/xf_rail.c:220]: (warning) Either the condition 'if(appWindow)' is redundant or there is possible null pointer dereference: appWindow.
[client/X11/xf_rail.c:217] -> [client/X11/xf_rail.c:220]: (warning) Either the condition 'if(appWindow)' is redundant or there is possible null pointer dereference: appWindow.
[client/X11/xf_rail.c:218] -> [client/X11/xf_rail.c:220]: (warning) Either the condition 'if(appWindow)' is redundant or there is possible null pointer dereference: appWindow.
[channels/tsmf/client/gstreamer/tsmf_X11.c:317] -> [channels/tsmf/client/gstreamer/tsmf_X11.c:322]: (warning) Either the condition '!decoder' is redundant or there is possible null pointer dereference: decoder.
[channels/tsmf/client/gstreamer/tsmf_X11.c:470] -> [channels/tsmf/client/gstreamer/tsmf_X11.c:475]: (warning) Either the condition '!decoder' is redundant or there is possible null pointer dereference: decoder.
[channels/tsmf/client/gstreamer/tsmf_X11.c:472] -> [channels/tsmf/client/gstreamer/tsmf_X11.c:475]: (warning) Either the condition '!decoder' is redundant or there is possible null pointer dereference: decoder.
[channels/tsmf/client/tsmf_media.c:179] -> [channels/tsmf/client/tsmf_media.c:181]: (warning) Either the condition '!stream' is redundant or there is possible null pointer dereference: stream.
[client/Windows/wf_cliprdr.c:2219] -> [client/Windows/wf_cliprdr.c:2222]: (warning) Either the condition '!formatDataResponse' is redundant or there is possible null pointer dereference: formatDataResponse
[client/Windows/wf_cliprdr.c:2445] -> [client/Windows/wf_cliprdr.c:2448]: (warning) Either the condition '!fileContentsResponse' is redundant or there is possible null pointer dereference: fileContentsResponse.
[client/X11/xf_cliprdr.c:911] -> [client/X11/xf_cliprdr.c:913]: (warning) Either the condition '!clipboard' is redundant or there is possible null pointer dereference: clipboard.
[client/X11/xf_graphics.c:504] -> [client/X11/xf_graphics.c:506]: (warning) Either the condition '!xfc' is redundant or there is possible null pointer dereference: xfc.
[libfreerdp/core/transport.c:861] -> [libfreerdp/core/transport.c:863]: (warning) Either the condition '!transport' is redundant or there is possible null pointer dereference: transport.
[server/shadow/shadow_server.c:777] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:778] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:779] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:781] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:782] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:783] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:784] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:785] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:787] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
[server/shadow/shadow_server.c:789] -> [server/shadow/shadow_server.c:791]: (warning) Either the condition '!server' is redundant or there is possible null pointer dereference: server.
* man pages are only build/installed if WITH_MANPAGES is enabled
* create a new cmake function install_freerdp_man to unified install man
pages
* install all man pages using the new function
* update the nightly packages accordingly
- fixed invalid, missing or additional arguments
- removed all type casts from arguments
- added missing (void*) typecasts for %p arguments
- use inttypes defines where appropriate
* fix spelling errors
* move man page from section 1 to section 7
* fix the man page header to match the actual section
* adapt the packages for wlog.7
Fixes#3632
nsc codec client doesn't work:
1. We should mark invalid region for software gdi
2. Checked the code before color conversion fix, the correct color format should be PIXEL_FORMAT_BGRX32_VF (corresponds to old PIXEL_FORMAT_XRGB32_VF)
3. For gdi:hw: xfc->bitmap_buffer is never used/initialized. However gdi->primary_buffer is always maintained. So use primary_buffer to hold the decoded bitmap data
iOS does not support Thread Local Storage.
Disabling it for now until a solution is found.
Print a compiler warning informing developers about this issue.
Global static variables do not work, if more than one instance
of an RDP client is running in the same process space.
Removed the varaibles where possible and replaced them with
thread local storage where necessary.
Add all missing dependencies found with --no-undefined. Since
dependencies aren't exported anymore (if not required) it is no necessary
to explicitly list all required libraries.
If a target is linked against libraries with cmake
(target_link_libraries) and the libraries are not marked as PRIVATE
they are "exported" and in case a other target is linked against this
target it is also linked against *all* (not private) libraries.
Without declaring private libraries PRIVATE a lot of over linking
(linking against unneeded libraries) was done.
- Added missing ConvertFromUnicode checks
- If ConvertToUnicode allocates memory, guarantee the null termination
similar to ConvertFromUnicode's implementation
- Fixed some TestUnicodeConversion.c CTest return values
- Added some CTests for ConvertFromUnicode and ConvertToUnicode
- Misc code and protocol hardening fixes in the surrounding code regions
that have been touched
* Make sure that numFormats has reasonable value
This will help catching errors like writing -1 as an unsigned number
of formats into the serialized stream, or trying to read the property
after someone else erroneosly messed with it, or other similar mistakes
which would result into reading and then sending garbage to the server.
We read the list xf_cliprdr_get_raw_server_formats() from an X window
property. Properties generally cannot be larger than 4 KB and each
format requires at least 5 bytes (most of them are named, though),
which gives us 512-ish limit on the number of formats we can squeeze
into the property.
However, it's hard to find an application that provides more than
20 formats (I've seen like 15 for MS Office apps), thus I believe
we can safely assume than anything that does not fit into a byte
means that we are reading garbage rather than a good format list.
* Check for the end of stream when reading format names
This also prevents reading garbage and getting segmentation faults
and Valgrind warnings when somebody somewhere sometimes forgets to
put a terminating null character where it belongs.
strnlen() and strndup() functions are provided by POSIX.1-2008
which we can reasonably expect to be available in 2016.
Certificates can now be accepted temporarily.
The callbacks for certificate validation have been
modified to extend the information presented to the user.
With this commit the "exported" components (usable with pkg-config and
cmake find module package)
* winpr - winpr library and headers
* freerdp - core library and headers
* freerdp-client - client specific library
* freerdp-server - server specific library
* rdtk - rdtk headers and library
To allow the installation of multiple different version (different major
number) the include files were moved into the respective sub folder:
freerdp -> freerdp{MAJOR}/freerdp (currently freerdp2/freerdp/)
winpr -> winpr{MAJOR}/winpr (currently winrp1/winpr/)
rdtk -> rdpk{MAJOR}/rdtk (currently rdtk0/rdtk/
The generated pkg-config and cmake find modules now also include the major
version number. Currently the following pkg-config are generated and
installed.
* winpr1
* freerdp2
* freerdp-server2
* freerdp-client2
* rdtk0
As cmake is able to handle multiple versions out of the box the
following can be used to find a specific module:
find_package(WinPR)
find_package(FreeRDP)
find_package(FreeRDP-Server)
find_package(FreeRDP-Client)
find_package(RdTk)
As cmake doesn't automatically resolve dependencies for packages it is
necessary to manually include the requirements. For example if
FreeRDP-Client is required WinPR and FreeRDP need to be included
(find_package) as well.
This commit also fixes the installation when STATIC_CHANNELS are built.
WITH STATIC_CHANNELS all channels are linked into libfreerdp-client, for
this all channels are generated as linker archive and linked together in
the final step. Before the intermediate linker archives were, although
not required and useful, installed. Same applies for server side
channels.
In case the old behaviour of not reverse-mapping the mouse buttons is
desirable, a command-line option is added to disable the mapping. This
option is made experimental for the time being.
The default is to do the reverse mapping, as this is the intuitive
behaviour (the mouse then works as it would on the console).
If XInput extension is available, then find the (first) pointer device
and use the button mapping of that one. If there are more than one
pointer devices, they could have different button mappings, but it is
not clear how this should be communicated to the RDP server.
If XInput is not available, attempt to fallback to the old global
mapping. (This mapping exists, but is not correct if there actually
is an XInput extension loaded, as it is then not used).
RDP expects to receive an indicator of the physical mouse button that
was pressed on the client, whereas X11 deliver a value for which
logical mouse button that was pressed.
This patch introduces a (reverse) mapping from logical mouse buttons to
physical mouse buttons, so that the RDP server can do correct mapping
for the event on its end.
However, no actual mapping is done here; this patch just introduces the
framework to do so. Thus, there should be no behavioural change from
this patch alone.
There is an implicit assumption that only the first three buttons are
mapped to eachother. Enabling more a general mapping would require
extensive changes to the event handling as fourth logical button and
up is used for special functionality such as wheel.
Horizontal mouse wheel input capabilities are now checked
and if available mouse buttons 6 and 7 are mapped to the
horizontal wheel for the X11 client.
The second step of raw transfer is to transfer the format data itself.
This has been already implemented in XFreeRDP before, but several
tweaks are required for it to work correctly.
The idea of raw data transfer is to request for _FREERDP_RAW clipboard
format while putting the actual formatId into _FREERDP_CLIPRDR property
where the requested data is expected to arrive to. Then the clipboard
owner will check for the real formatId and deliver the expected data.
This stays true, but the check is performed in a more straightforward
way, and CF_RAW format (numerically equal to zero) is not considered
an unknown destination format when performing (identity) conversions
with wClipboard. This is not an issue because wClipboard will allow
only identity conversion for CF_RAW, it will fail if something else
is going to be converted into CF_RAW.
The first part of raw transfer sequence is to transfer the format
list of the session A into the session B. Then we will be able to
request/reply with raw data using proper format IDs.
xf_cliprdr_server_format_list() of the session A now exposes the
raw server format list. As soon as the list is received, it is
serialized and put into _FREERDP_CLIPRDR_FORMATS property.
xf_cliprdr_get_requested_targets() of the session B now checks
whether the clipboard owner is a FreeRDP session with enabled
raw transfer capability. If it is, the raw format list is simply
extracted from _FREERDP_CLIPRDR_FORMATS of the clipboard owner.
Otherwise, the format list is populated from the usual TARGETS
clipboard format.
Some time ago there was a property _FREERDP_CLIPRDR_ID which was indended
to indicate that an XFreeRDP window owns a clipboard. This was necessary
for raw transfers. This property was used by xf_cliprdr_is_self_owned()
function. However, raw transfer support was broken and the meaning of
xf_cliprdr_is_self_owned() gradually changed into checking whether
the *current* window owns the clipboard, not just any XFreeRDP window.
Thus _FREERDP_CLIPRDR_ID was removed in a4580923e7 (xfreerdp/clipr:
fix self owned test and hardening).
However, now we are going to fix raw transfers and we need that property.
This patch reintroduces a similar property "_FREERDP_CLIPRDR_RAW" which
indicates that a window is an XFreeRDP window with enabled raw transfer.
It is currently used by xf_cliprdr_server_format_data_request() to
correctly request format data from another XFreeRDP instance via raw
transfer protocol.
This property can be queried from the clipboard owner with the function
xf_cliprdr_is_raw_transfer_available() and can be enabled or disabled
on the current window by xf_cliprdr_set_raw_transfer_enabled().
Disabling raw transfers will be necesary to correctly implement file
transfers in the future. However, currently raw transfers are always
enabled.
xf_cliprdr_send_data_response() is consistently called with NULL
data pointer as a way to report errors, but it was not setting
the msgFlags field accordingly.
Sometimes Windows sends strings with excess null terminating bytes.
For example, when one copies digits from calc.exe. At the same time,
some local applications freak out when they encounter null bytes
(at least LibreOffice is known to be replacing them with '#').
According to the specification of UTF8_STRING format [1], the string
data must not contain any trailing null bytes. So they all should be
trimmed, not only the last one.
Also, if the trailing null byte is not present, the length should not
be adjusted. For example, Firefox is actually sending "HTML Format"
without a null byte while Internet Explorer adds one. The spec for
text/html format [2] says nothing about the teminating null byte, so
we are free to remove it, but at least we should not mistakingly
delete '>' character of "</html>" tag when it is the last character.
[1] http://www.pps.univ-paris-diderot.fr/~jch/software/UTF8_STRING/UTF8_STRING.text
[2] https://www.ietf.org/rfc/rfc2854.txt
Clipboard formats are identified by numerical IDs and literal names.
We can keep using arbitrary defined IDs for local clipboard formats
as we are sure that they have some fixed meaning, but the server can
and will be using its own IDs, which can be different from ours for
the named formats.
Therefore:
1) A correct way to compare a local format to a remote one is
to check the names first, and only then compare their IDs.
(Extra care should be taken to support short format names.)
2) Server IDs cannot be used with wClipboard directly when dealing
with named formats. Format name should be used to extract correct
local ID for the use with Clipboard{Set,Get}Data().
Also, I find the notion of 'alternate' format IDs to be confusing.
We either deal with a fixed ID format (declared in <winpr/user.h>),
or a format that was given an arbitrary fixed ID for local use
(defined in <freerdp/channels/cliprdr.h>), or a remote format
identified by a pair of an ID and a name. Format IDs can be local
and remote, but there are no 'alternates'.
So now:
1) A new function xf_cliprdr_formats_equal() is used to compare
formats correctly in xf_cliprdr_get_server_format_by_atom()
when searching for a server format corresponding to a local
one, and in xf_cliprdr_server_format_list() when constructing
a local TARGETS list from the server format list.
2) Correct local format IDs are used with wClipboard conversions
by xf_cliprdr_process_requested_data() and
xf_cliprdr_server_format_data_response().
3) We refer to formatId and formatName when doing requests,
and srcFormatId and dstFormatId when doing conversions,
instead of using formatId and altFormatId for both purposes.
4) Server format ID and name are used to identify cached clipboard
contents. The name is compared directly as a pointer because it
will be a pointer from the same clipboard->serverFormats array.
Also, the clipboard contents are invalidated when format list
arrives, so xf_cliprdr_server_format_list() now also clears
the format ID and name together with the data.
The functions now have appropriate names which tell what exactly
they are searching for:
xf_cliprdr_get_client_format_by_id()
Get a client-provided format by client-side ID.
xf_cliprdr_get_client_format_by_atom()
Get a client-provided format by client-side format name.
xf_cliprdr_get_server_format_by_atom()
Get a corresponding server format by client-side format name.
The return types of functions have been adjusted accordingly and
correct formats are now used everywhere without mixing them up:
client-side formats are used for client -> server data flow,
while server-side ones are used for server -> client tranfers.
This resolves the issue #1414 as, for some reason, xfreerdp required
server format list to be present to be able to provide its own client
formats. Actually, we need only client format list to provide these.
Also, CF_RAW special case is handled in a more elegant way: it is
assumed to be present in every server format list (which is true).
This patch is needed when wanting to install binaries/libraries to other
locations than data. The linux distro Exherbo installs binaries and
libraries to /usr/<chost>/bin, /usr/<chost>/lib respectively but
manpages should still go in /usr/share/man/ because they are
architecture independent, without this patch they go in
/usr/<chost>/share/man unconditionally.
cmake documentation states:
DATAROOTDIR - read-only architecture-independent data root (share)
So this patch makes it use that so that its configurable.
