We don't want any stray exceptions as we are cleaning up, so handle any
still pending decoder errors by just logging them. We are already
shutting down so there is no need to abort the connection here.
Avoid duplicating all the memory mangement, and instead use the
BufferedOutStream as a base clase for all out streams that need an
intermediate buffer.
Safely discard large (extended) clipboard contents
Avoid having to buffer everything we want to discard, and instead do it
piece by piece. This is more efficient, and avoids hitting any limits on
the buffering.
Note that this is safe here because we already know we have all the
compressed data. It would not be safe for a general input stream.
These streams both need to change the corking state temporarily, but it
is important it is restored to the previous state or things might get
messed up.
For the zlib stream it would just leave things uncorked, which still
works but is less efficient.
But for the TLS stream it might make things very unresponsive as the
corking might be left on permanently, delaying packets indefinitely.
It seems MFT h264 decoder does not support frame cropping. Which
means that if frame width or height is not multiple of 16 then
decoded output can potentially be used with wrong offset. This
code adds explicit parsing of SPS to extract cropping information
to use, and will apply cropping if reported size differs from
expected.
Enable this automatically for developers so we increase the chance of
these problems getting caught. There is a risk of overhead though so
keep them disabled for release builds.
Unfortunately this error can be given by GnuTLS even though the
underlying stream still has data available. So stop trusting this value
and keep track of the underlying stream explicitly.
Avoid duplication, and add logging for some more error conditions so
it's possible to see in the logs why a resize has failed or produced
unexpected results.
This is a regression from ad0f061. If a VMware cursor rect was split up
over multiple read()s then the stream would become corrupted as we set
the restore point at the wrong place.
The generally recommended way is to include it from source files, not
headers. We had a mix of both. Let's try to be consistent and follow the
recommended way.
macOS' built in VNC server unfortunately sends the entire monitor in a
single rect, so we need to be prepared to buffer a lot of data in case
the monitor has a large resolution.
The certificates might still be fine using the system trust store, or
the user can make an exception. So let's just log and continue on.
This got very common after 960c7d2 where we now always have a default
value for these settings.
Keep ownership of second selection when first is lost
This fixes regression introduced by the extended clipboard extension.
Previously it was possible for the server to hold on to the CLIPBOARD
selection even if another application took ownership of PRIMARY. This is
important to handle the common use case of selecting something in order
to paste over it.
The new request based model doesn't readily support this as we assume
the client has lost its data once we push the new PRIMARY selection to
it. So to handle this we have the maintain a cache of the client's data,
and make sure to fill that cache before we do anything that might cause
the client to lose the data.