* Fixed format strings to match arguments
Reviewed and replaced all %d specifiers to match proper type
* Added proxy dynamic channel command type to log messages.
* fix moving a window shrinks it 14x7 when connect to server 2019
Signed-off-by: 2fly2 <wjatchd@163.com>
* use clang-format to apply correct formatting
Signed-off-by: 2fly2 <wjatchd@163.com>
Signed-off-by: 2fly2 <wjatchd@163.com>
* 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
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.
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.
[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.
akallabeth