summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
| * Fix the build of x11vnc when an out-of-tree build directory is usedDRC2012-03-111-1/+1
| |
| * Fix an issue that affects the existing Tight encoder as well as the ↵DRC2012-03-111-0/+9
| | | | | | | | | | | | | | | | | | | | newly-implemented Turbo encoder. The issue is that, when using the current libvncserver source, it is impossible to disable Tight JPEG encoding. The way Tight/Turbo viewers disable JPEG encoding is by simply not sending the Tight quality value, causing the server to use the default value of -1. Thus, cl->tightQualityLevel has to be set to -1 prior to processing the encodings message for this mechanism to work. Similarly, it is not guaranteed that the compress level will be set in the encodings message, so it is set to a default value prior to processing the message.
| * Add TurboVNC encoding support.DRC2012-03-118-8/+2395
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TurboVNC is a variant of TightVNC that uses the same client/server protocol (RFB version 3.8t), and thus it is fully cross-compatible with TightVNC and TigerVNC (with one exception, which is noted below.) Both the TightVNC and TurboVNC encoders analyze each rectangle, pick out regions of solid color to send separately, and send the remaining subrectangles using mono, indexed color, JPEG, or raw encoding, depending on the number of colors in the subrectangle. However, TurboVNC uses a fundamentally different selection algorithm to determine the appropriate subencoding to use for each subrectangle. Thus, while it sends a protocol stream that can be decoded by any TightVNC-compatible viewer, the mix of subencoding types in this protocol stream will be different from those generated by a TightVNC server. The research that led to TurboVNC is described in the following report: http://www.virtualgl.org/pmwiki/uploads/About/tighttoturbo.pdf. In summary: 20 RFB captures, representing "common" 2D and 3D application workloads (the 3D workloads were run using VirtualGL), were studied using the TightVNC encoder in isolation. Some of the analysis features in the TightVNC encoder, such as smoothness detection, were found to generate a lot of CPU usage with little or no benefit in compression, so those features were disabled. JPEG encoding was accelerated using libjpeg-turbo (which achieves a 2-4x speedup over plain libjpeg on modern x86 or ARM processors.) Finally, the "palette threshold" (minimum number of colors that the subrectangle must have before it is compressed using JPEG or raw) was adjusted to account for the fact that JPEG encoding is now quite a bit faster (meaning that we can now use it more without a CPU penalty.) TurboVNC has additional optimizations, such as the ability to count colors and encode JPEG images directly from the framebuffer without first translating the pixels into RGB. The TurboVNC encoder compares quite favorably in terms of compression ratio with TightVNC and generally encodes a great deal faster (often an order of magnitude or more.) The version of the TurboVNC encoder included in this patch is roughly equivalent to the one found in version 0.6 of the Unix TurboVNC Server, with a few minor patches integrated from TurboVNC 1.1. TurboVNC 1.0 added multi-threading capabilities, which can be added in later if desired (at the expense of making libvncserver depend on libpthread.) Because TurboVNC uses a fundamentally different mix of subencodings than TightVNC, because it uses the identical protocol (and thus a viewer really has no idea whether it's talking to a TightVNC or TurboVNC server), and because it doesn't support rfbTightPng (and in fact conflicts with it-- see below), the TurboVNC and TightVNC encoders cannot be enabled simultaneously. Compatibility: In *most* cases, a TurboVNC-enabled viewer is fully compatible with a TightVNC server, and vice versa. TurboVNC supports pseudo-encodings for specifying a fine-grained (1-100) quality scale and specifying chrominance subsampling. If a TurboVNC viewer sends those to a TightVNC server, then the TightVNC server ignores them, so the TurboVNC viewer also sends the quality on a 0-9 scale that the TightVNC server can understand. Similarly, the TurboVNC server checks first for fine-grained quality and subsampling pseudo-encodings from the viewer, and failing to receive those, it then checks for the TightVNC 0-9 quality pseudo-encoding. There is one case in which the two systems are not compatible, and that is when a TightVNC or TigerVNC viewer requests compression level 0 without JPEG from a TurboVNC server. For performance reasons, this causes the TurboVNC server to send images directly to the viewer, bypassing Zlib. When the TurboVNC server does this, it also sets bits 7-4 in the compression control byte to rfbTightNoZlib (0x0A), which is unfortunately the same value as rfbTightPng. Older TightVNC viewers that don't handle PNG will assume that the stream is uncompressed but still encapsulated in a Zlib structure, whereas newer PNG-supporting TightVNC viewers will assume that the stream is PNG. In either case, the viewer will probably crash. Since most VNC viewers don't expose compression level 0 in the GUI, this is a relatively rare situation. Description of changes: configure.ac -- Added support for libjpeg-turbo. If passed an argument of --with-turbovnc, configure will now run (or, if cross-compiling, just link) a test program that determines whether the libjpeg library being used is libjpeg-turbo. libjpeg-turbo must be used when building the TurboVNC encoder, because the TurboVNC encoder relies on the libjpeg-turbo colorspace extensions in order to compress images directly out of the framebuffer (which may be, for instance, BGRA rather than RGB.) libjpeg-turbo can optionally be used with the TightVNC encoder as well, but the speedup will only be marginal (the report linked above explains why in more detail, but basically it's because of Amdahl's Law. The TightVNC encoder was designed with the assumption that JPEG had a very high CPU cost, and thus JPEG is used only sparingly.) -- Added a new configure variable, JPEG_LDFLAGS. This is necessitated by the fact that libjpeg-turbo often distributes libjpeg.a and libjpeg.so in /opt/libjpeg-turbo/lib32 or /opt/libjpeg-turbo/lib64, and many people prefer to statically link with it. Thus, more flexibility is needed than is provided by --with-jpeg. If JPEG_LDFLAGS is specified, then it overrides the changes to LDFLAGS enacted by --with-jpeg (but --with-jpeg is still used to set the include path.) The addition of JPEG_LDFLAGS necessitated replacing AC_CHECK_LIB with AC_LINK_IFELSE (because AC_CHECK_LIB automatically sets LIBS to -ljpeg, which is not what we want if we're, for instance, linking statically with libjpeg-turbo.) -- configure does not check for PNG support if TurboVNC encoding is enabled. This prevents the rfbSendRectEncodingTightPng() function from being compiled in, since the TurboVNC encoder doesn't (and can't) support it. common/turbojpeg.c, common/turbojpeg.h -- TurboJPEG is a simple API used to compress and decompress JPEG images in memory. It was originally implemented because it was desirable to use different types of underlying technologies to compress JPEG on different platforms (mediaLib on SPARC, Quicktime on PPC Macs, Intel Performance Primitives, etc.) These days, however, libjpeg-turbo is the only underlying technology used by TurboVNC, so TurboJPEG's purpose is largely just code simplicity and flexibility. Thus, since there is no real need for libvncserver to use any technology other than libjpeg-turbo for compressing JPEG, the TurboJPEG wrapper for libjpeg-turbo has been included in-tree so that libvncserver can be directly linked with libjpeg-turbo. This is convenient because many modern Linux distros (Fedora, Ubuntu, etc.) now ship libjpeg-turbo as their default libjpeg library. libvncserver/rfbserver.c -- Added logic to check for the TurboVNC fine-grained quality level and subsampling encodings and to map Tight (0-9) quality levels to appropriate fine-grained quality level and subsampling values if communicating with a TightVNC/TigerVNC viewer. libvncserver/turbo.c -- TurboVNC encoder (compiled instead of libvncserver/tight.c) rfb/rfb.h -- Added support for the TurboVNC subsampling level rfb/rfbproto.h -- Added constants for the TurboVNC fine quality level and subsampling encodings as well as the rfbTightNoZlib constant and notes on its usage.
* | Added support for UltraVNC Single Click as originally proposed by Noobius ↵Monkey2012-04-231-0/+8
| | | | | | | | | | | | (Boobius) on 6/1/11. Original thread: http://sourceforge.net/tracker/?func=detail&aid=3310255&group_id=32584&atid=405860
* | Add Philip to AUTHORS.Christian Beier2012-04-151-1/+1
| |
* | LibVNCClient: Fix build with no SSL/TLS library available.Christian Beier2012-04-151-0/+2
| |
* | LibVNCClient: properly free the openssl session stuff on shutdown.Christian Beier2012-04-151-13/+14
| |
* | LibVNCClient: Remove all those WITH_CLIENT_TLS #ifdefs and move GnuTLS ↵Christian Beier2012-04-155-72/+16
| | | | | | | | specific functionality into tls_gnutls.c.
* | Unify GnuTLS vs OpenSSL build systems stuff between libvncclient and ↵Christian Beier2012-04-141-9/+8
| | | | | | | | libvncserver.
* | Add the OpenSSL libvncclient TLS version to the build system.Christian Beier2012-04-144-1/+657
| |
* | Update our copy of noVNC.Christian Beier2012-04-1215-144/+1221
| | | | | | | | Bugfixes and support for tight encoding with zlib.
* | Merge branch 'server-ipv6'Christian Beier2012-04-0212-48/+516
|\ \
| * | IPv6 support for LibVNCServer, part four: add copyright notices to files ↵Christian Beier2012-04-024-0/+4
| | | | | | | | | | | | with non-trivial changes.
| * | IPv6 support for LibVNCServer, part three: make reverse connections ↵Christian Beier2012-03-106-15/+174
| | | | | | | | | | | | | | | | | | | | | | | | IPv6-capable. 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.
| * | IPv6 support for LibVNCServer, part onepointseven: Plug a memleak.Christian Beier2012-03-101-0/+3
| | | | | | | | | | | | | | | We have to properly free the addrinfo struct when jumping out of the function.
| * | IPv6 support for LibVNCServer, part twopointone: properly surround IPv6 ↵Christian Beier2012-03-091-1/+9
| | | | | | | | | | | | | | | | | | addresses with [] for noVNC URL. Some browsers omit the square brackets in document.location.hostname, so add them if missing.
| * | IPv6 support for LibVNCServer, part two: Let the http server listen on IPv6, ↵Christian Beier2012-02-274-15/+90
| | | | | | | | | | | | | | | | | | too. As done with the RFB sockets, this uses a separate-socket approach as well.
| * | IPv6 support for LibVNCServer, part onepointsix: fix a small logic error.Christian Beier2012-02-271-1/+1
| | | | | | | | | | | | | | | Without this, we would have gotten a stale IPv4 socket in a race condition.
| * | IPv6 support for LibVNCServer, part onepointfive: Fix compilation with IPv6 ↵Christian Beier2012-02-272-0/+8
| | | | | | | | | | | | | | | | | | missing. There was an oversight that crept in...
| * | IPv6 support for LibVNCServer, part one: accept IPv4 and IPv6 connections.Christian Beier2012-02-205-19/+230
| |/ | | | | | | | | | | | | | | | | 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 <[email protected]>
* | SDLvncviewer: map Apple/Windows keys correctlyJohannes Schindelin2012-03-291-3/+2
| | | | | | | | Signed-off-by: Johannes Schindelin <[email protected]>
* | gitignore the compiled gtkvncclientJohannes Schindelin2012-03-291-0/+1
| | | | | | | | Signed-off-by: Johannes Schindelin <[email protected]>
* | SDLvncviewer: fix the SDL_KEYUP issueJohannes Schindelin2012-03-291-6/+13
|/ | | | | | | | | | | 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 <[email protected]>
* Here is a port of SDLvncviewer to GTK+2.Mateus Cesar Groess2012-02-114-3/+683
| | | | | | | | 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 <[email protected]>
* Update AUTHORS.Christian Beier2012-02-111-1/+2
|
* Support Mac OS X vnc client with no passwordKyle J. McKay2012-02-113-10/+81
| | | | | | 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.
* Add Luca to the AUTHORSJohannes Schindelin2012-02-041-1/+1
| | | | Signed-off-by: Johannes Schindelin <[email protected]>
* Add an optional parameter to specify the ip address for reverse connectionsLuca Stauble2012-02-034-3/+25
| | | | | | | | | | | | | | | | 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 <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
* Merge branch 'websockets' of https://github.com/kanaka/libvncserverChristian Beier2012-01-122-18/+31
|\
| * websockets: removed debug messageGernot Tenchio2012-01-121-1/+1
| |
| * websockets: restore errno after logging an errorGernot Tenchio2012-01-121-6/+17
| |
| * cmake: adapted to latest websocket crypto changesGernot Tenchio2012-01-121-11/+13
| |
* | Small changes to LibNVCClient doxygen documentation.Christian Beier2011-12-151-22/+23
| |
* | Merge branch 'master' of https://github.com/watkipet/libvncserverChristian Beier2011-12-151-1/+215
|\ \
| * | Added comments.Peter Watkins2011-10-261-1/+215
| | |
* | | Fix build error when libpng is available, but libjpeg is not.Christian Beier2011-12-011-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Use AM_SILENT_RULES only when it's actually available.Christian Beier2011-12-011-1/+1
| | | | | | | | | | | | | | | Otherwise building breaks with older make versions. Happens on OS X 10.6 for instance.
* | | Merge branch 'included-novnc'Christian Beier2011-11-1774-56/+7514
|\ \ \
| * | | Move the java stuff into webclients/java-applet.Christian Beier2011-11-0922-6/+11
| | | |
| * | | Rename 'classes' dir to 'webclients'.Christian Beier2011-11-0970-10/+10
| | | |
| * | | novnc client: use the client's notion about the server hostname instead of ↵Christian Beier2011-11-092-5/+14
| | | | | | | | | | | | | | | | what the server thinks.
| * | | Fix tiny typo.Christian Beier2011-11-091-1/+1
| | | |
| * | | httpd: fix sending of binary data such as images.Christian Beier2011-10-061-17/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We do this simply by omitting the content-type and let the browser decide upon the mime-type of the sent file. Only exception is 'index.vnc', where we do set the content-type since some browsers fail to detect it's html when it's ending in '.vnc' Also, remove superfluous #defines. We close the connection always.
| * | | Fix typo && use proper website.Christian Beier2011-10-061-1/+1
| | | |
| * | | Add noVNC HTML5 client connect possibility to our http server.Christian Beier2011-10-0444-8/+7462
| | | | | | | | | | | | | | | | Pure JavaScript, no Java plugin required anymore! (But a recent browser...)
* | | | Add 0.9.8.2 NEWS entry.Christian Beier2011-11-091-0/+3
| | | |
* | | | When GetCredential() callback is not set, don't use authentications ↵Christian Beier2011-11-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | requiring it. The auth methods that employ Getcredential() will only be used if the client's GetCredential callback is actually set.
* | | | Update ChangeLog for 0.9.8.1.Christian Beier2011-11-081-0/+18
| | | |
* | | | Update version number in autotools && cmake, NEWS entry.Christian Beier2011-11-083-3/+6
| | | |
* | | | Fix deadlock in threaded mode when using nested rfbClientIteratorNext() calls.Christian Beier2011-10-261-15/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
generated by cgit v1.2.1 (git 2.18.0) at 2025-03-04 08:02:00 +0000