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.
Marc-André Moreau