Bugfixes and support for tight encoding with zlib.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Keys got stuck because unicode is 0 upon SDL_KEYUP events, even if the
same key event sets unicode correctly in SDL_KEYDOWN events.

Work around that for the common case (ASCII) using the fact that both SDL
and X11 keysyms were created with ASCII compatibility in mind. So as long
as we type ASCII symbols, we can map things trivially.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Besided making libvncserver reverseVNC IPv6-aware, this introduces some changes
on the client side as well to make clients listen on IPv6 sockets, too. Like
the server side, this also uses a separate-socket approach.

We have to properly free the addrinfo struct when jumping out of the
function.

IPv6 support for LibVNCServer, part twopointone: properly surround IPv6 addresses with [] for noVNC URL.

Some browsers omit the square brackets in document.location.hostname, so add them if missing.

As done with the RFB sockets, this uses a separate-socket approach as well.

Without this, we would have gotten a stale IPv4 socket in a race
condition.

There was an oversight that crept in...

This uses a separate-socket approach since there are systems that do not
support dual binding sockets under *any* circumstances, for instance
OpenBSD. Using separate sockets for IPv4 and IPv6 is thus more portable
than having a v6 socket handle v4 connections as well.
Signed-off-by: Christian Beier <dontmind@freeshell.org>

I think it may encourage people to implement more features for the viewer,
because a GTK GUI seems to be easier to implement than a SDL one
(and it is more integrated with the major Linux Desktops out there).
Signed-off-by: Christian Beier <dontmind@freeshell.org>

Support connections from the Mac OS X built-in VNC client to
LibVNCServers running with no password and advertising a server
version of 3.7 or greater.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

For security reasons, it can be important to limit which IP addresses a
LibVNCClient-based client should listen for reverse connections. This
commit adds that option.

To preserve binary backwards-compatibility, the field was added to the end
of the rfbclient struct, and the function ListenAtTcpPort retains its
signature (but calls the new ListenAtTcpPortAndAddress).

[jes: shortened the commit subject, added a longer explanation in the
commit body and adjusted style]
Signed-off-by: Luca Stauble <gnekoz@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The png stuff in tight.c depends on code in tight.c that uses libjpeg
features. We could probably seperate that, but for now the dependency
for 'tight' goes:

PNG depends on JPEG depends on ZLIB.

This is reflected in Makefile.am now.

NB: Building tight.c with JPEG but without PNG is still possible,
    but nor the other way around.

Otherwise building breaks with older make versions. Happens on OS X
10.6 for instance.

The auth methods that employ Getcredential() will only be used if the client's
GetCredential callback is actually set.

Lengthy explanation follows...

First, the scenario before this patch:

We have three clients 1,2,3 connected. The main thread loops through
them using rfbClientIteratorNext() (loop L1) and is currently at
client 2 i.e. client 2's cl_2->refCount is 1. At this point we need to
loop again through the clients, with cl_2->refCount == 1, i.e. do a
loop L2 nested within loop L1.

BUT: Now client 2 disconnects, it's clientInput thread terminates its
clientOutput thread and calls rfbClientConnectionGone(). This LOCKs
clientListMutex and WAITs for cl_2->refCount to become 0. This means
this thread waits for the main thread to release cl_2. Waiting, with
clientListMutex LOCKed!

Meanwhile, the main thread is about to begin the inner
rfbClientIteratorNext() loop L2. The first call to rfbClientIteratorNext()
LOCKs clientListMutex. BAAM. This mutex is locked by cl2's clientInput
thread and is only released when cl_2->refCount becomes 0. The main thread
would decrement cl_2->refCount when it would continue with loop L1. But
it's waiting for cl2's clientInput thread to release clientListMutex. Which
never happens since this one's waiting for the main thread to decrement
cl_2->refCount. DEADLOCK.

Now, situation with this patch:

Same as above, but when client 2 disconnects it's clientInput thread
rfbClientConnectionGone(). This again LOCKs clientListMutex, removes cl_2
from the linked list and UNLOCKS clientListMutex. The WAIT for
cl_2->refCount to become 0 is _after_ that. Waiting, with
clientListMutex UNLOCKed!

Therefore, the main thread can continue, do the inner loop L2 (now only
looping through 1,3 - 2 was removed from the linked list) and continue with
loop L1, finally decrementing cl_2->refCount, allowing cl2's clientInput
thread to continue and terminate. The resources held by cl2 are not free()'d
by rfbClientConnectionGone until cl2->refCount becomes 0, i.e. loop L1 has
released cl2.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>