| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Make the API consisitent by requiring the caller to check what the client
supports before calling any of the write* functions. This avoids the
confusion that the functions might not always do anything.
|
|
|
|
|
|
| |
Avoid having the callers need to know about the different variants
of these functions and instead have the writer pick the most appropriate
extension.
|
|
|
|
|
|
| |
This is what the protocol requires, rather than sending what the
client specified in the request. This should be the same in practice
except for failures and possibly some races.
|
|
|
|
|
|
| |
ServerParams should contain the server state and not information about
client settings or capabilities. Move those things up a level to the
CConnection object.
|
|
|
|
|
|
| |
No need to have one setting for each extension. All the client code
needs to indicate is if it supports resize. The common code can then
map this to relevant extensions.
|
|
|
|
| |
It needs to be validated and take effect in the server first.
|
|
|
|
| |
These were either completely unused, or always true.
|
|
|
|
|
| |
Tight is the default preferred encoding, so we don't really need
special handling for it to be first in the list.
|
|
|
|
|
| |
This is a lot safer and cleaner. The old code had a fixed size that
we didn't properly keep track of.
|
|
|
|
|
|
| |
Make sure all methods only write what is given as arguments, and
avoid side effects by getting data from parameter objects. This keeps
things readable in the calling code.
|
|
|
|
|
| |
It's a generic client thing, so abstract it in to the common library.
Makes it easier to integrate with other common code.
|
|
|
|
|
|
|
| |
Avoid using the callbacks used for runtime changes for the initial
setup. They weren't really useful anyway as you could not allocate
a framebuffer without also knowing the pixel format. So make things
more clear by letting serverInit() get the initial settings.
|
|
|
|
|
| |
Add an explicit callback for subclasses to do their startup in. This
makes it easier to do proper ordering, and avoids mistakes.
|
| |
|
|
|
|
|
| |
Better to check the actual list of supported encodings directly.
Makes parts more readable, and no risk of getting out of sync.
|
|
|
|
|
| |
No need to spread things out. Keep all of the handling in a single
place to make things clearer.
|
|
|
|
|
|
| |
Now that we've split out server state to ServerParams, ConnParams
only contains state for a client. Rename the class and variables
to reflect this.
|
|
|
|
|
|
| |
We need to track different things in the server and client, so
separate things to two independent structures to keep things more
clear.
|
|
|
|
|
|
|
| |
Avoid direct access to the screen dimensions and layout so that we
can make sure it stays sane. This also makes sure the layout is
properly updated when we only get the screen dimensions from the
server.
|
|
|
|
|
| |
That object is just a container for the current state. Move the I/O
to the classes already doing such stuff.
|
|
|
|
|
| |
We should not be including server headers from client code. It was
not even needed, so simply remove it.
|
|\ |
|
| |
| |
| |
| |
| | |
Applets don't work anymore so remove everything that has to do
with serving them.
|
|\ \ |
|
| |/ |
|
|/
|
|
|
| |
Makes it easier to debug TLS issues, and to see the effect of
altering the priority string.
|
|
|
|
|
|
| |
In theory we could return to communicate without TLS after a
shutdown. It also makes sure the connection object isn't left
completely without streams.
|
|
|
|
|
|
| |
The streams depend on the session and can crash the program if they
are removed in the wrong order. Do a general cleanup of the life time
management of the streams.
|
|
|
|
|
| |
There is already an implicit connection between them, so let's make
it explicit. This allows easy lookup outside of the processMsg() function.
|
|
|
|
|
| |
If we leave it at something random we'll get an invalid delete
if the handshake fails.
|
|
|
|
|
| |
These are just confusing and obfuscating. Do a normal delete of
these objects instead.
|
|
|
|
|
|
|
| |
If we are still in slow start then we haven't discovered the actual
bandwidth limit yet. We also rely on the caller causing a bit of
congestion to detect the limit. So report a higher bandwidth estimate
than what we've currently tested in this scenario.
|
|
|
|
|
|
|
|
|
|
|
| |
Loosen the definition of "lossless" a bit so that we can use high
quality JPEG to refresh damaged parts of the screen. Although this
isn't bit perfect, it is close enough that most users will not be
able to tell the difference.
Level 9 is used rather than level 8 because some monitors have
exaggerated contrast that allows the artefacts from level 8 to be
noticeable.
|
| |
|
|
|
|
|
| |
Most encoders don't have a palette mode, so don't force them to
specify a dummy value to the Encoder base class constructor.
|
|
|
|
|
|
| |
If we have plenty of bandwidth then CPU might be the limiting resource.
Unfortunately we don't have a good number for that limit, so add a
conservative hard coded value.
|
|
|
|
|
| |
If we're out of time then we will definitely overshoot, so don't even
try.
|
|
|
|
|
| |
The update size is in bytes, but we are counting pixels. So make
sure we convert things properly before comparing.
|
|
|
|
|
|
|
|
| |
If an area recently changed then we can guess that it will most likely
change again very soon. In such a case it is meaningless to send a
lossless refresh as it will directly be overwritten. Keep track of
such areas and avoid refreshing them until we no longer see any
changes to them.
|
|
|
|
|
| |
The reference for "dueTime" wasn't properly updated when this code
was refactored from a static method to a normal object method.
|
|
|
|
|
| |
The compiler isn't smart enough to figure all of these out, so
restructure things a bit to avoid warnings.
|
|
|
|
|
| |
Makes it possible to use certificates from all popular CAs with
TigerVNC.
|
| |
|
| |
|
|\ |
|
| | |
|
| |
| |
| |
| |
| | |
We use polymorphic exception objects, so catching by value invokes
the copy constructor and stuff that we don't really want.
|
| |
| |
| |
| | |
Fixes #652.
|
| | |
|