| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| |
| |
| | |
Adds an optional graph to the viewer to display current frame rate,
pixel rate and network bandwidth. Makes it easier to debug and test
performance related issues.
|
| |
| |
| |
| |
| | |
Even if there are no pixels it will still trigger sanity checks
when we start throwing bogus coordinates around.
|
| |
| |
| |
| | |
It adds a lot of noise to the debug output with little gain.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This will allow us to use better formats that preserve the entire
alpha channel.
|
| | |
|
| | |
|
| |
| |
| |
| | |
We can no longer assume maskRect() will tolerate uncropped data.
|
| |
| |
| |
| |
| |
| | |
We need to restore the previous, more complex API in order to
easily handle masks now that we no longer accept out-of-bounds
operations.
|
| |
| |
| |
| |
| |
| | |
There has been multiple attempts at tricking decoders to exceed
the boundaries of the active pixel buffer. Add extra checks to
prevent such invalid access.
|
| | |
|
|/
|
|
|
|
| |
It can be triggered by RRE message with subrectangle out of framebuffer
boundaries. It may prevent the same kind of issue caused by evil message
from another encoding too.
|
|\ |
|
| |
| |
| |
| |
| | |
The hextileDecodexx functions do not properly check for out-of-bounds writes,
which allows a malicious server to overwrite parts of the stack.
|
|/ |
|
|
|
|
|
|
|
| |
This bug was introduced in c6df31db. A non-blocking socket that did
not have any more space would busy loop until the write succeeded.
Instead now it returns without any action, just as it did before
the bug was introduced.
|
|
|
|
|
| |
Any caller using add or remove should also be able to list the
sockets.
|
|
|
|
|
| |
Some of these were excessively large because of redundant factors
in the size calculation.
|
| |
|
| |
|
|
|
|
|
|
| |
These are reference counted so it is important to retain symmetry
between the calls. Failure to do so will result in bad memory access
and crashes.
|
|
|
|
|
| |
168b92c broke the handling that assumes display 100 and above are
actually a port number.
|
|
|
|
| |
Use the platform independent primitives instead.
|
| |
|
| |
|
|
|
|
|
| |
It now does more validation, and handles unescaped IPv6 addresses
better.
|
|
|
|
|
|
|
| |
We might be linking our Xregion and libX11 into the same binary,
causing a clash between the symbols. In theory they should be
compatible, but that's not guaranteed. Avoid the issue by adding
a "vnc" prefix to our version.
|
| |
|
|
|
|
|
| |
We've stolen the Xregion code from libX11, so let's keep the same
header naming so that it is easier to keep things in sync.
|
| |
|
|
|
|
|
|
| |
There might be stuff lingering in the buffer simply because flush()
hasn't been called in a while, rather than because the transport is
congested.
|
|
|
|
|
|
| |
We now get notifications when the output buffer empties, and we
already caught incoming RTT pongs, meaning we can now react at the
proper time to retry a congested update rather than use a timer.
|
|
|
|
|
| |
This makes sure we keep the socket busy even if one rect takes some
time to encode.
|
|
|
|
|
|
| |
What to do when a socket is writeable should be handled in the
RFB core code as there may be other events we want to fire off
when this happens.
|
|
|
|
| |
The logic was a bit confusing and superfluous.
|
|
|
|
| |
We haven't supported such an old version of Windows for some time.
|
| |
|
| |
|
|
|
|
|
| |
There are more platforms than x86_64 that need -fPIC, so include
it whenever possible.
|
|
|
|
|
|
| |
The previous detection would fail if the socket closed before we
had time to inspect it, which got us stuck in a loop as we would
try (and fail) to do accept() on a non-listening socket.
|
| |
|
|
|
|
|
| |
Only C++11 allows omitting the class keyword, so include it so
the code compiles with older compilers.
|
|
|
|
|
|
| |
Parsing a filter might be the first thing we do so we need to
make sure the socket subsystem is running so that we can look
up names.
|
| |
|
|
|
|
|
| |
They just end up burning CPU fighting each other without much
improvement to the decoding time beyond four threads.
|
| |
|