summaryrefslogtreecommitdiffstats
path: root/configure.ac
Commit message (Collapse)AuthorAgeFilesLines
* Move vncterm to https://github.com/LibVNC/vncterm.Christian Beier2014-09-091-1/+0
|
* Remove x11vnc from autotools build system.factor-out-x11vncChristian Beier2014-09-031-429/+1
|
* Update sourceforge links to point to github.Christian Beier2014-04-051-1/+1
|
* LibVNCClient: Add H.264 encoding for framebuffer updatesDavid Verbeiren2013-01-251-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements support in LibVNCClient for framebuffer updates encoded as H.264 frames. Hardware accelerated decoding is performed using VA API. This is experimental support to let the community explore the possibilities offered by the potential bandwidth and latency reductions that H.264 encoding allows. This may be particularly useful for use cases such as online gaming, hosted desktops, hosted set top boxes... This patch only provides the client side support and is meant to be used with corresponding server-side support, as provided by an upcoming patch for qemu ui/vnc module (to view the display of a virtual machine executing under QEMU). With this H.264-based encoding, if multiple framebuffer update messages are generated for a single server framebuffer modification, the H.264 frame data is sent only with the first update message. Subsequent update framebuffer messages will contain only the coordinates and size of the additional updated regions. Instructions/Requirements: * The patch should be applied on top of the previous patch I submitted with minor enhancements to the gtkvncviewer application: http://sourceforge.net/mailarchive/message.php?msg_id=30323804 * Currently only works with libva 1.0: use branch "v1.0-branch" for libva and intel-driver. Those can be built as follows: cd libva git checkout v1.0-branch ./autogen.sh make sudo make install cd .. git clone git://anongit.freedesktop.org/vaapi/intel-driver cd intel-driver git checkout v1.0-branch ./autogen.sh make sudo make install Signed-off-by: David Verbeiren <david.verbeiren@intel.com>
* Use htobeNN(3) to convert numbers in websocket.c.Raphael Kubo da Costa2012-09-141-1/+1
| | | | | | | | | byteswap.h exists only on glibc, so building libvncserver with websockets support was not possible in other systems. Replace the inclusion of byteswap.h and the WS_* definitions with calls to htobeNN, which should perform the same conversions, be more portable and avoid the need to check for the platform's endianness.
* Do not hardcode the need for libresolv.Raphael Kubo da Costa2012-09-141-2/+11
| | | | | | | | | | libresolv is only present on systems which use glibc; platforms such as FreeBSD have __b64_ntop as part of libc itself. Improve the detection process and only link against libresolv if it exists on the system, and remember to reset CMAKE_REQUIRED_LIBRARIES after performing the necessary tests, since we do not always want to link against libresolv.
* Add Compile Time Version Test Defines.Christian Beier2012-05-231-0/+5
|
* Bump version to 0.9.10.Christian Beier2012-05-051-2/+2
|
* Enable building DLLs with MinGW32.Christian Beier2012-05-041-0/+2
|
* Make PKG_CHECK_MODULES fail non-fatal.Christian Beier2012-04-301-2/+2
| | | | These check for optional modules.
* Fix build when no libjpeg is available.Christian Beier2012-04-261-10/+6
|
* Better check for Linux build.Christian Beier2012-04-251-2/+2
|
* Bump version to 0.9.9.Christian Beier2012-04-251-2/+2
|
* Merge branch 'turbovnc'Christian Beier2012-04-251-3/+56
|\ | | | | | | | | Conflicts, resolved manually: AUTHORS
| * Replace TightVNC encoder with TurboVNC encoder. This patch is the result of ↵DRC2012-03-261-20/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | further research and discussion that revealed the following: -- TightPng encoding and the rfbTightNoZlib extension need not conflict. Since TightPng is a separate encoding type, not supported by TurboVNC-compatible viewers, then the rfbTightNoZlib extension can be used solely whenever the encoding type is Tight and disabled with the encoding type is TightPng. -- In the TightVNC encoder, compression levels above 5 are basically useless. On the set of 20 low-level datasets that were used to design the TurboVNC encoder (these include the eight 2D application captures that were also used when designing the TightVNC encoder, as well as 12 3D application captures provided by the VirtualGL Project-- see http://www.virtualgl.org/pmwiki/uploads/About/tighttoturbo.pdf), moving from Compression Level (CL) 5 to CL 9 in the TightVNC encoder did not increase the compression ratio of any datasets more than 10%, and the compression ratio only increased by more than 5% on four of them. The compression ratio actually decreased a few percent on five of them. In exchange for this paltry increase in compression ratio, the CPU usage, on average, went up by a factor of 5. Thus, for all intents and purposes, TightVNC CL 5 provides the "best useful compression" for that encoder. -- TurboVNC's best compression level (CL 2) compresses 3D and video workloads significantly more "tightly" than TightVNC CL 5 (~70% better, in the aggregate) but does not quite achieve the same level of compression with 2D workloads (~20% worse, in the aggregate.) This decrease in compression ratio may or may not be noticeable, since many of the datasets it affects are not performance-critical (such as the console output of a compilation, etc.) However, for peace of mind, it was still desirable to have a mode that compressed with equal "tightness" to TightVNC CL 5, since we proposed to replace that encoder entirely. -- A new mode was discovered in the TurboVNC encoder that produces, in the aggregate, similar compression ratios on 2D datasets as TightVNC CL 5. That new mode involves using Zlib level 7 (the same level used by TightVNC CL 5) but setting the "palette threshold" to 256, so that indexed color encoding is used whenever possible. This mode reduces bandwidth only marginally (typically 10-20%) relative to TurboVNC CL 2 on low-color workloads, in exchange for nearly doubling CPU usage, and it does not benefit high-color workloads at all (since those are usually encoded with JPEG.) However, it provides a means of reproducing the same "tightness" as the TightVNC encoder on 2D workloads without sacrificing any compression for 3D/video workloads, and without using any more CPU time than necessary. -- The TurboVNC encoder still performs as well or better than the TightVNC encoder when plain libjpeg is used instead of libjpeg-turbo. Specific notes follow: common/turbojpeg.c common/turbojpeg.h: Added code to emulate the libjpeg-turbo colorspace extensions, so that the TurboJPEG wrapper can be used with plain libjpeg as well. This required updating the TurboJPEG wrapper to the latest code from libjpeg-turbo 1.2.0, mainly because the TurboJPEG 1.2 API handles pixel formats in a much cleaner way, which made the conversion code easier to write. It also eases the maintenance to have the wrapper synced as much as possible with the upstream code base (so I can merge any relevant bug fixes that are discovered upstream.) The libvncserver version of the TurboJPEG wrapper is a "lite" version, containing only the JPEG compression/decompression code and not the lossless transform, YUV encoding/decoding, and dynamic buffer allocation features from TurboJPEG 1.2. configure.ac: Removed the --with-turbovnc option. configure still checks for the presence of libjpeg-turbo, but only for the purposes of printing a performance warning if it isn't available. rfb/rfb.h: Fix a bug introduced with the initial TurboVNC encoder patch. We cannot use tightQualityLevel for the TurboVNC 1-100 quality level, because tightQualityLevel is also used by ZRLE. Thus, a new parameter (turboQualityLevel) was created. rfb/rfbproto.h: Remove TurboVNC-specific #ifdefs and language libvncserver/rfbserver.c: Remove TurboVNC-specific #ifdefs. Fix afore-mentioned tightQualityLevel bug. libvncserver/tight.c: Replaced the TightVNC encoder with the TurboVNC encoder. Relative to the initial TurboVNC encoder patch, this patch also: -- Adds TightPng support to the TurboVNC encoder -- Adds the afore-mentioned low-bandwidth mode, which is mapped externally to Compression Level 9 test/*: Included TJUnitTest (a regression test for the TurboJPEG wrapper) as well as TJBench (a benchmark for same.) These are useful for ensuring that the wrapper still functions correctly and performantly if it needs to be modified for whatever reason. Both of these programs are derived from libjpeg-turbo 1.2.0. As with the TurboJPEG wrapper, they do not contain the more advanced features of TurboJPEG 1.2, such as YUV encoding/decoding and lossless transforms.
| * Add TurboVNC encoding support.DRC2012-03-111-4/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Unify GnuTLS vs OpenSSL build systems stuff between libvncclient and ↵Christian Beier2012-04-141-9/+8
|/ | | | libvncserver.
* Here is a port of SDLvncviewer to GTK+2.Mateus Cesar Groess2012-02-111-0/+4
| | | | | | | | 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>
* 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-171-2/+3
|\
| * Move the java stuff into webclients/java-applet.included-novncChristian Beier2011-11-091-1/+2
| |
| * Rename 'classes' dir to 'webclients'.Christian Beier2011-11-091-2/+2
| |
* | Update version number in autotools && cmake, NEWS entry.Christian Beier2011-11-081-2/+2
|/
* Merge branch 'websockets'Christian Beier2011-10-041-91/+165
|\
| * This build warning is a libvncserver one, not for x11vnc.websocketsChristian Beier2011-10-041-17/+14
| | | | | | | | | | Also, make it warn more generally when no known encryption lib is available.
| * Autotools: Fix OpenSSL and GnuTLS advertisement.Christian Beier2011-09-191-1/+2
| |
| * configure: Add AM_SILENT_RULESGernot Tenchio2011-09-191-0/+1
| | | | | | | | | | Working with “silent make mode” makes debugging a lot of easier since warnings wont shadowed by useless compiler noise
| * websockets: add GnuTLS and OpenSSL supportGernot Tenchio2011-08-171-93/+94
| | | | | | | | | | | | | | | | | | | | For now, only OpenSSL support is activated through configure, since GnuTLS is only used in LibVNCClient. [jes: separated this out from the commit adding encryption support, added autoconf support.] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
| * websockets: Initial WebSockets support.Joel Martin2011-08-171-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Has a bug: WebSocket client disconnects are not detected. rfbSendFramebufferUpdate is doing a MSG_PEEK recv to determine if enough data is available which prevents a disconnect from being detected. Otherwise it's working pretty well. [jes: moved added struct members to the end for binary compatibility with previous LibVNCServer versions, removed an unused variable] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
| * tightPng: Add initial tightPng encoding support.Joel Martin2011-07-221-0/+55
| | | | | | | | | | | | | | http://wiki.qemu.org/VNC_Tight_PNG Signed-off-by: Joel Martin <github@martintribe.org> Signed-off-by: Christian Beier <dontmind@freeshell.org>
* | Adopt autotools build system to Android.Christian Beier2011-07-231-0/+8
|/ | | | LibVNCServer/LibVNCClient now build for Android!
* Add libvncserver.pc and libvncclient.pc files.Vic Lee2011-03-281-0/+2
| | | | | Signed-off-by: Vic Lee <llyzs@163.com> Signed-off-by: Christian Beier <dontmind@freeshell.org>
* Next version will be 0.9.8.Christian Beier2011-03-101-2/+2
|
* Move zippy.c to examples.Christian Beier2011-03-101-1/+0
|
* Add ARD (Apple Remote Desktop) security type supportVic Lee2011-01-311-0/+16
| | | | | Signed-off-by: Vic Lee <llyzs@163.com> Signed-off-by: Christian Beier <dontmind@freeshell.org>
* x11vnc: Use opengl to read screen on macosx. non-deprecated macosx ↵runge2010-12-291-0/+8
| | | | interfaces for input injection.
* x11vnc: force --with-system-libvncserver to use correct headers.runge2010-12-211-0/+14
|
* Fix MinGW32 checking for IPv6.Christian Beier2010-07-141-2/+12
| | | | | Signed-off-by: Christian Beier <dontmind@freeshell.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* libvncclient: add ipv6 supportVic Lee2010-07-081-0/+9
| | | | | | | | [jes: pulled the "host" declarations into the conditionally compiled blocks where that variable is used. Also fixed non-IPv6 connections.] Signed-off-by: Vic Lee <llyzs@163.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* I think two HAVE_X's were missed.runge2010-03-211-2/+2
|
* Rename HAVE_X -> HAVE_X11Johannes Schindelin2010-03-131-7/+7
| | | | | | This change is just for consistency reasons. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* Change GnuTLS minimum requirement to 2.4.0Vic Lee2009-11-101-1/+1
| | | | | Signed-off-by: Vic Lee <llyzs@163.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* Merge branch 'VeNCrypt'Johannes Schindelin2009-11-021-0/+16
|\
| * Fallback to --without-client-tls if GNUTLS could not be foundJohannes Schindelin2009-10-021-1/+1
| | | | | | | | Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
| * Add anonymous TLS support in libvncclientVic Lee2009-10-021-0/+16
| | | | | | | | Signed-off-by: Vic Lee <llyzs@163.com>
* | mingw32 crosscompile fixes.Christian Beier2009-10-021-4/+18
|/ | | | | | | | | | | SOCKET is redefined in winsock2.h so #undef it where winsock2.h is included. The changes in rfbproto.c circumvent crosscompiler errors like 'S_IFMT' undeclared ...', the Makefile.am changes avoid building linux specific stuff for a win32 host target. Also added configure option to specify sdl-config. Signed-off-by: Christian Beier <dontmind@freeshell.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* Thread safety for zrle, zlib, tight.runge2009-05-211-0/+7
| | | | Proposed tight security type fix for debian bug 517422.
* x11vnc: add kludge to experiment with turbovnc.runge2009-02-281-1/+1
|
* clean up build flagsdscho2009-02-031-0/+1
| | | | | | | | | | | | | | | | | The flag handling (both compiler options and include paths) are a mess at the moment. There is no point in forcing "-O2 -g" when these are already the defaults, and if someone changes the defaults, chances are good they don't want you clobbering their choices. The -Wall flag should be handled in configure and thrown into CFLAGS once rather than every Makefile.am. Plus, this way we can control which compilers the flag actually gets used with. Finally, the INCLUDES variable is for -I paths, not AM_CFLAGS. Nor should it contain -I. as this is already in the default includes setup. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* configure: use _cv_ in cache var namedscho2009-02-031-1/+1
| | | | | | | Newer autoconf fails if _cv_ is not in the cache var name. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
OpenPOWER on IntegriCloud