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).
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.
refreshRectSupport and suppressOutputSupport of the General
Capability Set (MS-RDPBCGR 2.2.7.1.1) are server-only flags
that indicate whether the Refresh Rect or Suppress Output
PDUs are supported by the server.
Therefore in rdp_read_general_capability_set() we must only
change the respective settings if we are not in server mode.
WTSStartRemoteControlSession doesn't allow to specify additional flags
therefore add a new extended version WTSStartRemoteControlSessionEx
with an additional "flags" parameter.
The following flags are defined:
REMOTECONTROL_FLAG_DISABLE_KEYBOARD - disable keyboard input
REMOTECONTROL_FLAG_DISABLE_MOUSE - disable mouse input
REMOTECONTROL_FLAG_DISABLE_INPUT - disable input (keyboard and mouse)
This patch fixes a bug with mstsc connecting to a RDP security only FreeRDP server.
It seems like the mstsc shipped with Windows Seven considers packets after the nego_failure
packet as an error. So after trying to do TLS, depending on the timing, mstsc can print an
error message instead of retrying to connect with RDP security. With this patch, we
don't send the MCS disconnect message when the negociation has failed.
