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 ;).
Add option WITH_DEBUG_RINGBUFFER to enable/disable ringbuffer debugging
at compile time.
Even if it is possible to filter specific wlog tags it's not yet
possible to exclude one or more and ringbuffer adds massive debugging
output if enabled and WLOG_LEVEL is set to DEBUG.
Commit 0357a38e31 modified the function
fastpath_send_update_pdu() to check if the desired update is possible
by checking the payload size against the computed maxLength and the
clients's advertised max request size.
If the check failed that commit added a workaround which simply
copied the payload to a slow path updade.
This workaround is totally flawed and causes protocol errors:
- the fast path update code is not checked and required data format
conversions are missing
- depending on the fast path update code rdp_send_data_pdu() would
have to be called with differend data pdu type values but the
workaround always uses DATA_PDU_TYPE_UPDATE
- the workaround does not check if the total size would exceed
the maximum possible size for a slow path update
The check if a fast path output is actually possible with the
passed parameters is basically a good idea.
However, if that check fails it would only indicate an error in
the server implementation who must not generate updates that
exceed the client's max request size.
Even though a slow-path conversion would be possible there is
much more involved than simply copying the payload stream.
In addition it is highly doubtful if there is a benefit at all.
Even the oldest rdesktop and windows ce clients do support fast
path and although some lack the multi-fragment update capability
we cannot really send larger updates using slow-path outputs.
For the reasons elucidated above, I have removed the workaround
but kept a modified version of the check if a fast-path output
is possible at all.
Commit 0357a38e31 has added some code
without any effect.
That commit added code to rdp_read_capability_sets() to check if
CAPSET_TYPE_MULTI_FRAGMENT_UPDATE was not received which caused
settings->MultifragMaxRequestSize to be set to 0.
- this was done in the wrong place because we do these kind
of checks in rdp_recv_confirm_active() by consulting the
variable settings->ReceivedCapabilities[]
- the code had no effect at all because MultifragMaxRequestSize gets
set to FASTPATH_FRAGMENT_SAFE_SIZE in rdp_recv_confirm_active()
if the CAPSET_TYPE_MULTI_FRAGMENT_UPDATE was not received.
Extend rdp_pointer with function SetPosition. Can then be used by
clients support setting pointer by server which might be used in
shadowing scenarios.
