GFX and SurfaceBits commands share a common codec backend.
Recreating all codec context on GFX initialization will break
clients that are decoding SurfaceBits codec while having the GFX
channel initialized.
(cherry picked from commit 91a6ac131370c48a742b8bcc58ad188bb7ed60f8)
Thanks to Sunglin and HuanGMz of the Knownsec 404 security team and pangzi of pwnzen
(cherry picked from commit 5592cb2e10da42592af98f5533d2e42181e86821)
This fixes the following defect reported by covscan tool:
libfreerdp/gdi/gfx.c:144: missing_unlock: Returning without unlocking "update->mux".
(cherry picked from commit 914808f62c)
- fixed and consolitate the duplicated code for sending the
CLOSE_REQUEST_PDU to the server into dvcman_close_channel
- call dvcman_close_channel if a dynamic channel plugin fails
to process the received channel data
- rdpegfx: don't try to remove a non-existing cache entry,
return an error instead which now will close the channel, as
expected by Microsoft's windows protocols test suite
Since the EGFX Reset Graphics PDU seems to be optional,
the graphicsReset variable (which is updated in that PDU's handler)
should be removed from the rdp_gdi struct with the next change
in public headers (as in freerdp v3).
There are still some clients that expect and check it and therefore
we keep it for now, initialized with TRUE.
sdas
If no library can be loaded at runtime ignore H264 capabilities.
This allows a build with only OpenH264 support and dynamic loading
enabled to function when no openh264 library was detected.
Since these functions were called from 2 different threads
(main thread or dynamic channel) depending on fastpath or
gfx channel use lock between these.
If not locked the invalid region may be accessed from both
threads and lead to crashes as experienced with nightly df280a7ff
To fix#4825 GFX functions must now aquire a lock before accessing surfaces.
This prevents simultaneous update of internal data by client and gfx threads.
Also enforce return value checks, where not already done.
