If we apply -mssse3 to files that don't need it, gcc may automagically
generate instructions that will not run on certain CPUs. This breaks the
runtime feature detection code (IsProcessorFeaturePresent).
Fixes: https://github.com/FreeRDP/FreeRDP/issues/4308
My method was to find the LIBAVUTIL_VERSION_* at the commit where the
updated AV_ prefixed constants became available, add one "micro" version
to it, then if it's not at least that version, provide the unprefixed
constant. It just so happens that the same commit introduced all
the AV_* constants.
The AV_ prefixed constants have been available since
ffmpeg@def97856de6021965db86c25a732d78689bd6bb0 (2015-07-07), or version
2.8.
The non-prefixed constants are set to be removed in the next ffmpeg
release, and were removed in
ffmpeg@302554835e39b79b977ed60c9afe81b44590dfef (2016-12-05).
Since ec027bf dynamic resolution is broken when used with egfx. Before that commit
we were tracking a server sent resize by setting a DesktopResize callback. This callback
is called when the desktop is resized by the server. Anyway the problem was that when this
callback is called, the activation sequence is not always completed, which were leading to
some freeze with 2012r2 servers (sending packets before the sequence is finished).
So with the faulty commit, we are tracking server resizes by subscribing to the Actived
event, that is called at the end of a reactivation sequence, so we're sure to not send packets
when not fully activated.
Anyway the issue that shows on (#4330) is that when you use egfx, no reactivation sequence happens,
the server only sends a ResetGraphics message with the new size, and so we miss the resized event.
This fix introduces a new GraphicsReset event, makes the display channel subscribe to that event,
and react accordingly.
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.
"(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.
