Makes it easier to troubleshoot keyboard issues by printing exactly
what key events the server is getting from the client.

The bug fix in b64dbf2 didn't account for the proper request
region in the case of continuous updates. Make sure we use the
proper variable for which region we've sent updates for.

A request may be for only part of the frame buffer, meaning we cannot
discard all changes just because we've send out an update. There might
still be modified areas remaining that haven't been requested yet.

Variables were reused a bit too heavily and it was possible to get
the logic at a point where the server would try to render a cursor
where it wasn't needed, and the empty update rect would cause a
crash. Clear things up by introducing some more explicit variables.

There has been some confusion if fillRect() should accept a buffer
or a pixel. This can cause misrendering if your data is not in the
native endian order. A buffer makes more sense here though, and
is what most of the callers are already assuming, so change the
API to follow that.

It doesn't really make sense anymore given that settings might come
from the GUI or configuration and not only the command line.

Makes it more sane what type to use when interacting with this class.

Also avoids %lld which isn't supported on Windows.

The constants used here are unsigned so it makes more sense that
the parameters are as well.

Either by casting, or switching to a more appropriate type
for the variable.

The previous FIXME was incorrect. The old code did in fact continue
looking over the entire area. This commit restores that old behaviour.

It knows more details so it can track things better.

It had regressed in performance compared to 1.3. This brings it back
up to the same speed.

The only class that cares if connections are reversed or not is
VNCSConnectionST so let it keep track of this fact.

Needed for some tests.

On some platforms va_list might be defined as something that causes
ambiguity and results in the wrong function being called.

This allows us to simplify things by getting rid of some old
compatibility code. People should really be using current versions
of GnuTLS anyway to stay secure.

It just adds noise and you can't really tell which timer it is
anyway without more logging in other places.

The internal Xorg headers are very incompatible with C++ and we've had
to resort to all kinds of hacks in order to include them in our C++
code. This approach isn't really viable long term so restructure things
so that we have a glue layer written in C that bridges the Xorg core
with the RFB classes.

Both SSecurityVeNCrypt and SSecurityStack are wrappers around other
security objects, so they need to delegate the properties of those
sub-objects properly.

A read-only client should not be allowed to kick out other clients.
It will be forced into shared mode, or refused the connection, depending
on the neverShared parameter.

So clients with limited access rights can not affect it.

This reverts commit 39d7dc043a.

We should be secure by default, even if it might cause a performance
hit. Those who wish to make that trade off are more likely to notice
the lack of performance than others noticing the lack of security.

It's often useful to see if encryption was used, and how the user
authenticated (if at all).

Try to read second password (for read only access) from rfbauth file. If client
sent second password instead of first one, allow him read only access.

SConnection has AccessRights property that specifies what connected client can
do. Set this property to value given by SSecurity after successful
authentication. This way individual SSecurity subclasses can accept clients but
restrict their access.