To do this I've swapped _strnicmp with memcmp. Seemless, but does lock it to the restrictions of that function.
Signed-off-by: Jason Plum <jplum@archlinuxarm.org>
Command line detection is run with dummy settings where not everything
is allocated. Collections (device, dynamic channel and static
channel) didn't handle this case properly.
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.
Situation: we have fragmented TPKT PDU without two last bytes
(or one last byte - for fast-path) in network stack.
First call to transport_read_pdu() works normally, read
available bytes and exit with status 0 - no whole PDU readed.
Before second call this missed bytes arrive.
Optionally with next PDU.
In second call header parsing code unconditionally read this
two bytes(one byte) despite this is not header bytes.
And increase stream position, so stream now contains whole PDU.
This cause (pduLength - Stream_GetPosition(s)) calculation to be 0.
So transport_read_layer_bytes()-->transport_read_layer() return 0
and transport_read_pdu() exits with "not enough data is available"
status.
If next PDU isn't available next calls to transport_read_pdu()
give same result.
If next PDU arrive - (pduLength - Stream_GetPosition(s)) will be
less than 0. Stream position will grow, grow and grow on each call.
And transport_read_pdu() never signals that PDU is readed.
Caught on Android FreeRDP client with high RDP traffic (several MBytes/s).
1. Don't draw to screen if server sends begin/end paint
messages without any real updates.
2. Redraw only summary region that covers really invalidated
part of screen.
Keepalive settings are usually (depending on the implementation) only
used if the TCP connection is idle.
If the network is interrupted/disconnected/... click or keyboard input
generates outgoing traffic therefore the connection isn't idle
anymore and keepalives might not be used causing the connection to
stay open and the client to stall.
Linux 2.6.36 added a TCP_USER_TIMEOUT TCP socket option that lets a
program specify the maximum time transmitted data may remain
unacknowledged before TCP will close the corresponding connection with
ETIMEDOUT.
Setting TCP_USER_TIMEOUT allows us to detect a network problem (like
cable disconnect) even if the connection isn't idle.
