Small cleanup of passing around decorations flag.
Limit PercentScreen to single monitor vs. entire desktop. IMO - this is better behavior in a multimonitor environment.
Handle fullscreen windows better:
1. Ensure that size hints are set to allow resizing before setting a window to fullscreen as some window managers do not behave properly.
2. Handle fullscreen toggles without destroying and recreating window.
3. Use NET_WM_STATE_FULLSCREEN Extended Window Manager Hint for fullscreen functionality
4. Use the NET_WM_FULLSCREEN_MONITORS Extended Window Manager Hint when appropriate
5. When a single monitor fullscreen is requested - use the current monitor(as determined from mouse location)
6. Handle cases where there is no local monitor at coordinate 0,0. The Windows server expect there to be a monitor at this location, so we maintain offset if necessary between our local primary monitor and the server side primary monitor located at 0,0.
Remove use of the visibleOffset, this completely breaks the display of all windows except for the main application window. Instead,
just maintain a local offset correction of the windowOffset.
Apply workaround to determining the workArea for remote app mode.
Since XWarpPointer generates an pointer motion event, as if the mouse
was moved by hand, xfreerdp sends back the received mouse position to
the server. This behavior is wrong since pointer positions set via
server pointer update pdu shouldn't get sent back to the server
(it's not a "real" mouse move).
To fix this problem change the x windows event mask to not handle
pointer motion events before setting the new pointer position and change
it back again afterwards.
Possible downside of this is that some pointer motion events might get
lost but this shouldn't be noticeable.
Thanks to nfedera for the neat idea ;).
The input->FocusInEvent callback implementations (normal and fast-path) have
always sent the mouse position even if the pointer was outside of the freerdp
client area. In addition xfreerdp used the wrong pointer coordinates which
were relative to the root window instead of its own.
On focus-in the pointer position must only be sent if the pointer is
currently within the program's client area. However, the clients had no way
to pass that information to input->FocusInEvent which required an API change.
- removed mouse pointer x, y parameters from input interface's FocusInEvent
- clients are responsible to call input->MouseEvent on focus-in if necessary
- fixed xfreerdp and wfreerdp accordingly
Note: /gdi:sw was working fine, this commit fixes /gdi:hw
* calculate color channel shifts based on X11 visual color masks
* fast path to skip conversion if visual color masks equal rdp color masks
* successfully tested 8/15/16/24/32 bpp rdp sessions on 16/24/32 bpp visuals
xf_cliprdr_process_selection_notify calls xf_cliprdr_send_client_format_list
if the SelectionNotify event property was None.
xf_cliprdr_send_client_format_list called XConvertSelection even if there
was no clipboard owner. In that case the XServer generates a SelectionNotify
event to the requestor (us) with property None and so on ...
The most obvious fix is to ensure that XConvertSelection is not called if
the owner is None which is done in this commit.
In case of server side initiated desktop resize it could happen that the
client was "scaling" even if smart-sizing was disabled. The reason for
this was that the "scaled" width and height was set when the X Configure
event arrived but not in xf_desktop_resize.
* fixed crash on server-initiated desktop resize and fullscreen toggle with /gdi:sw
* implemented desktop resize for /gdi:sw
* check for availibility of XRender extension and show error messages if a setting would require it
* fixed compile error if xrender devel packages are missing
* fixed bug with server-initiated desktop resize in fullscreen mode
Most of xfreerdp's hw gdi callbacks did the the same X11 drawing operation
twice: Initially on the primary pixmap to keep the back buffer up to date
and then directly on the window in order to see the result.
This sequence is followed by a call to gdi_InvalidateRegion() to mark the
rectangular area of the drawing operation.
Since in xfreerdp's current design (or better current evolved state) the
backbuffer pixmap is obligatory, all drawing operations directly targeting
the window are redundant because of the subsequent EndPaint (mapped to
xf_hw_end_paint) where the damaged region is copied from the backbuffer
to the drawable.
- removed X11 drawing operations which directly target the window drawable
- fixed some errors in the calculation of the required update regions
X11 gdi polyline has been broken by commit 3de5c62.
We don't need to convert the point coordinates if XDrawLines is called with
coordinate mode CoordModePrevious.
The fOpRedundant field of the GlyphIndex primary drawing order
(MS-RDPEGDI, chapter 2.2.2.2.1.1.2.13) was neglected which resulted in some
severe text rendering errors.
"libfreerdp" consisted of multiple (small) single libraries. If the cmake
option MONOLITHIC was used only one library was build combining all of
the libfreerdp-* libraries.
The only exceptions to this are libfreerdp-server and libfreerdp-client these
are build as separate libraries.
This commit obsoltes non-monolithic builds and makes monolithic builds
the default. The cmake option MONOLITHIC is also removed.
Conflicts:
channels/drdynvc/client/dvcman.c
include/freerdp/codec/h264.h
libfreerdp/codec/h264.c after this merge h264 doesn't work anymore!!
libfreerdp/utils/svc_plugin.c
* client/X11/xf_client.c (xf_pre_connect): Set the field `colormap' of
`struct xfContext' to the default colormap.
* client/X11/xfreerdp.h (xf_gdi_get_color): Declare new external function.
* client/X11/xf_gdi.c (xf_gdi_get_color): Define new external function.
Use xf_gdi_get_color() to get the appropriate X color index from the GDI
color representation.
* client/X11/xf_graphics.c: Likewise.
representation.
* client/X11/xf_gdi.c:
Use freerdp_color_convert_drawing_order_color_to_gdi_color() to convert
from drawing order color representation to GDI color representation
troughout.
* client/X11/xf_graphics.c: Likewise.
* Zeroing xevent helped address some erratic behavior.
* valgrind complained about using xfBitmap uninitialized
during shutdown, traced it back to the initialization.
Bitmap_Prototype->size > sizeof(rdpBitmap).
* Early exit from recv_tpkt_pdu is necessary to address
a shutdown crash - the channelId value was being used
without being set in the disconnect case.
