* 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
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.
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.
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)
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.
* 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.
Armin Novak