The coordinates from RDP ROP commands do not (always) have
0,0 as the origin of the drawing operation.
Adjust the coordinates to our local coordinate system.
freerdp_disconnect must only be called, if the connection
was established. Otherwise all resources are cleaned up twice
leading to double free and other issues.
Some window managers do not support _NET_WM_FULLSCREEN_MONITORS.
In that case multimonitor fullscreen does not properly work, so
add a path resizing the window over all screens instead.
Based on @erbth pull request, adding proper X11 atom checks.
"(oid[0] << 4) & (oid[1] & 0x0F)" statement is always 0. It is not
problem currently because the only OID which is written by this
function should have 0 there. The function to read/write are pretty
limited anyway and can't work properly with all kind of OIDs. Maybe
it would be better to hardcode the OID there without decoding
and encoding. But those functions are already there so let's improve
them a bit according the spec and warn about limited set of
supported OIDs.
See:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb540809
Stream_Seek() is used, but consequently Stream_SetPosition() is used
for position obtained by Stream_GetPosition() immediatelly before
Stream_Seek(). Let's remove this stream position changes due to its
redundancy.
p is 20 and r is 1 in the last iteration of fips_expand_key_bits,
which means that buf[21] is read (of BYTE buf[21];). However,
the value is not needed, because it is consequently discarded by
"c & 0xfe" statement. Let's do not read buf[p + 1] when r is 1
to avoid this.
* fix StatusW_Call to rely and use SCardStatusW
* fix trace call in StatusW_Call - needs to be called after the sizes
are set
* unify SCardStatus functions for pcsc - let the internal function handle unicode directly
This fixes an issue with size calculations of SCardStatusW.
If the display channel is available we use it to allow the user to resize the
xfreerdp window. When the window is resized we announce a new monitor layout and
the server reacts by doing a reactivation sequence to the new size.
The minimum window size is limited to 300x300 as 2012 servers crash horribly
if we send them a smaller layout.
The PCSC SCard implementation in winpr tried to rename reader and group
names received from PCSC to something similar to what the windows smart
card service would return.
Because of the following reasons this mapping was removed:
* reader names are not standardized
* no mapping of reader name should be required at all
* the mapping added extra complexity
* the mapping didn't produce the same names as if the reader was
directly connected on windows (or redirected from a windows host)
In case there are situations where this is nevertheless required this
feature can simple be (re-)implemented a part of the smart card channel.
Also the formatting was fixed.
SCardAddReaderName isn't part of the SCard API.
Note: removing this also removes the possibility to redirect single
smartcard readers with /smartcard:READERNAME. However this features
wasn't implemented in a general way and will be re-added as part of
the smart card channel directly.
The state tracking/modifications (presumably thought as optimization?!) in
PCSC_SCardGetStatusChange_Internal cause a lot of applications to behave
incorrectly and/or hang. Ideally no modifications of the states should
be necessary as PCSC implements the same API as passed over the channel.
In case SCardGetStatusChange returned an error the call didn't return
any data but STATUS_NO_MEMORY as the calloc failed. This caused problems
with multiple applications server side (hangs and incorrect behavior).
Now the case when no readers are returned is handed correctly and the
data is also filled and send if the call fails.
The smart card channel tried to mimic mstsc's behavior on if an IRP was
processed synchronously or asynchronously. As the channel uses one thread per
context it could happen, especially with PCSC, that the main
channel thread was blocked waiting for an smart card operation to
complete. To prevent that behavior only call known safe functions in the
main thread (like CreateContext) and call the rest asynchronously.
For example the channel would block if a ListReaders is invoked on
the same context where a GetStatusChange (infinite timeout)
was already pending. Only when a status change happened the channel
would continue.
Note: Due to the one context per thread design it's important that
cancel isn't queued an alway run synchronously. Otherwise a specific
context might lock.
Device control calls always returned SCARD_S_SUCCESS even if an error
occurred. This caused server side software (including the card manager)
to behave incorrectly.
According to MS-RDPESC the smart card channel must set the IoStatus to
an NTSTATUS in case a encoding or decoding error happens. The smart card
channel did this correctly but the output stream was modified
incorrectly causing the smart card remote manager to stop in error
cases.
