summaryrefslogtreecommitdiffstats
path: root/rfb
Commit message (Collapse)AuthorAgeFilesLines
* CMake: add all function checks that used to be in configure.acChristian Beier2017-04-211-0/+42
| | | | Fixes #174
* CMake: properly name rfbconfig.h cmake templateChristian Beier2017-04-211-0/+0
|
* CMake: set LIBVNCSERVER_HAVE_FORK in rfbconfig.h if fork() foundChristian Beier2017-04-181-0/+3
|
* CMake: set LIBVNCSERVER_HAVE_LIBSSL in rfbconfig.h if OpenSSL foundChristian Beier2017-04-181-0/+3
|
* CMake: detect mmap() and write result to rfbconfig.hChristian Beier2017-04-181-0/+3
|
* Fix building for Android and add build instructions to READMEChristian Beier2017-03-261-0/+5
|
* Merge branch 'circle' of https://github.com/ldmnyblzs/libvncserver into ↵Christian Beier2017-03-261-0/+15
|\ | | | | | | | | | | | | ldmnyblzs-circle Conflicts: libvncclient/rfbproto.c
| * Add function pointers for every type of rectangleBalazs Ludmany2016-06-291-0/+15
| |
* | rfbproto: re-add erroneously removed SOCKET definitionChristian Beier2017-02-211-0/+1
| |
* | rfbproto: remove SOCKET redefinitionsChristian Beier2017-02-211-3/+0
| |
* | Fix "rfbBool's size is not 1" runtime error with MSVCChristian Beier2017-02-211-1/+1
| |
* | CMake: that file ain't used no moreChristian Beier2017-01-311-4/+0
| |
* | Various #ifdef fixes to allow building with MSVC2014Christian Beier2017-01-281-0/+1
| |
* | CMake: add a HAVE_SYS_UIO_H flag to rfbconfig.hChristian Beier2017-01-281-0/+3
| |
* | Fix LibVNCClient compilation with MSVC 2014Christian Beier2017-01-281-0/+4
|/
* Fix rfbClientSwap64IfLE broken in fe7df89fb1777b4fd303d5a601541f6062caf8eaChristian Beier2016-06-051-1/+1
|
* Merge pull request #84 from plettix/masterChristian Beier2016-06-052-4/+4
|\ | | | | fix for issue 81
| * shift fixes - if an integer is a negative number then the return value of ↵plettix2015-07-222-4/+4
| | | | | | | | "Swap32IfLE" was -1
* | Only include endian.h if present on system.Christian Beier2016-05-301-2/+2
| |
* | Merge pull request #105 from cgeorges82/masterChristian Beier2016-05-301-0/+21
|\ \ | | | | | | fix for issue #97. Also, this fixes cmake builds for other platforms.
| * | Append IPv6 option in CMake ProjectCédric Georges2016-03-051-0/+21
| | |
* | | Merge pull request #103 from rdieter/masterChristian Beier2016-04-241-1/+1
|\ \ \ | | | | | | | | use namespaced vnc_max macro (issue #102)
| * | | use namespaced rfbMax macro (issue #102)Rex Dieter2016-04-181-1/+1
| |/ / | | | | | | | | | Not using generic 'max', avoids conflicts with stl_algobase.h
* | | Merge pull request #118 from gbdj/threadsafe-100-squashChristian Beier2016-04-241-0/+6
|\ \ \ | | | | | | | | libvncclient/tls_gnutls.c: Add hooks to WriteToTLS() for optional protection by mutex. (Squashed)
| * | | libvncclient/tls_gnutls.c: Add hooks to WriteToTLS() for optional protection ↵gbdj2016-04-231-0/+6
| |/ / | | | | | | | | | | | | | | | | | | | | | by mutex. Fix upstream issue #100 Squashed commit of the pull request #101 : commit 1c7e01e81862bc46508e675e83c74cc6d63224b0 commit 1e749b094d6696380d3f0540a00138d7e3427874
* | | Increase MAX_ENCODINGS value to accommodate more client encodingszbierak2016-04-131-1/+1
|/ / | | | | | | Resolves #112
* | Be a bit clearer with the cursorshape documentation for libvncclient.Christian Beier2015-12-031-1/+4
| |
* | Properly document HandleCursorShape and GotCursorShapeProc.Christian Beier2015-12-031-2/+11
| |
* | Merge pull request #90 from stweil/fixChristian Beier2015-10-101-4/+4
|\ \ | | | | | | Fix some recently introduced regressions
| * | Fix definition of POSIX data typesStefan Weil2015-10-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | Commit 92f558482d94c5152174a1983a40863bd6b07911 added stdint.h to get the type definitions, but included it after the first use of int8_t in builds for Windows. Signed-off-by: Stefan Weil <sw@weilnetz.de>
| * | Fix endianness detectionStefan Weil2015-10-101-2/+3
| |/ | | | | | | | | | | | | | | | | | | Commit 97f442ef2aa65ade6bea11e90054c57b90abbaca tried to improve the endianness detection, but introduced a typo and problems for Windows builds (no endian.h, different definition of LIBVNCSERVER_WORDS_BIGENDIAN). Fix both issues. Signed-off-by: Stefan Weil <sw@weilnetz.de>
* | Fix some typos (found by codespell)Stefan Weil2015-10-093-6/+6
|/ | | | Signed-off-by: Stefan Weil <sw@weilnetz.de>
* Instead of letting the build system define endianess, rely on endian.h.Christian Beier2015-05-281-5/+5
|
* Do away with rfbint.h generation and use stdint.h directly instead.Christian Beier2015-05-281-3/+0
|
* Revert "LibVNCClient: Add H.264 encoding for framebuffer updates"Christian Beier2015-04-171-15/+0
| | | | | | | | This reverts commit d891478ec985660c03f95cffda0e6a1ad4ba350c. Conflicts: configure.ac libvncclient/h264.c
* Fix handling of multiple VNC commands per websockets frameFloris Bos2015-01-171-0/+1
| | | | | | | | | | | | | - When processing input, check if there is any extra data pending in the internal websocket frame and SSL buffers. - Prevents input events lagging behind because they get stuck in one of the buffers. Data pending in our own buffers cannot be detected with select() so was not processed until more input arrives from the network. - Closes # 55 Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
* Those are generally the windows headers, not just MinGWDaniel Cohen Gindi2014-09-201-2/+2
|
* Generally adjusting headers for compiling on windows without the mixing of ↵Daniel Cohen Gindi2014-09-201-0/+4
| | | | Winsock 1 and 2.
* MSVC: Use the Unix emulation headersDaniel Cohen Gindi2014-09-021-0/+4
| | | | | | [JES: provided commit message, split out unrelated changes] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* Use correct winsock headerDaniel Cohen Gindi2014-09-021-1/+1
| | | | | | | | | We link to ws2_32.lib which corresponds to the winsock2.h header, not the winsock.h header. [JES: fixed commit message] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* Remove unneeded #ifdefs.Christian Beier2013-01-251-3/+2
|
* Fix ABI compatibility issue.Christian Beier2013-01-251-1/+4
|
* LibVNCClient: Add H.264 encoding for framebuffer updatesDavid Verbeiren2013-01-252-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+6
| | | | | | | | | 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.
* Use C-style comments in rfbconfig.h.cmake and C source code.Raphael Kubo da Costa2012-09-142-5/+5
| | | | | Using C++-style comments when building the code with -ansi does not work, so be more conservative with the comment style.
* Add Compile Time Version Test Defines.Christian Beier2012-05-231-0/+4
|
* LibVNCServer: Include ws2tcpip.h if it's available.Christian Beier2012-05-031-0/+4
| | | | Needed for the IPv6 stuff.
* Only try to build TightPNG stuff when libjpeg is available.Christian Beier2012-04-301-8/+2
| | | | | | | TightPNG replaces the ZLIB stuff int Tight encoding with PNG. It still uses JPEG rects as well. Theoretically, we could build TightPNG with only libpng and libjpeg - without zlib - but libpng depends on zlib, so this is kinda moot.
* Merge branch 'turbovnc'Christian Beier2012-04-252-4/+35
|\ | | | | | | | | Conflicts, resolved manually: AUTHORS
| * Replace TightVNC encoder with TurboVNC encoder. This patch is the result of ↵DRC2012-03-262-15/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
generated by cgit v1.2.1 (git 2.18.0) at 2025-01-12 20:53:21 +0000