summaryrefslogtreecommitdiffstats
path: root/rfb
Commit message (Collapse)AuthorAgeFilesLines
* mingw32 crosscompile fixes.Christian Beier2009-10-021-0/+1
| | | | | | | | | | | 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/+11
| | | | Proposed tight security type fix for debian bug 517422.
* Export the functions SupportsClient2Server and SupportsServer2Clientllyzs2009-05-201-0/+3
| | | | | | | These are useful functions for VNC clients, so let's export them for everybody to use. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* libvncclient: Unix sockets support by Ben KlopfensteinBen Klopfenstein2009-05-121-0/+1
| | | | Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* Fix compilation in the absence of libjpegdscho2008-04-281-1/+1
| | | | | | | | The JPEG library is not necessarily installed everywhere, and sometimes it is outright undesirable to compile with JPEG support, e.g. when the server is not very fast. So fix the compilation for that case. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* Move tightQualityLevel out of the JPEG specific partdscho2008-01-311-1/+2
| | | | | | | | The variable tightQualityLevel is used for ZYWRLE compression, too, so if libjpeg is not present, but libz is, we still need to have that struct member. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* Make ZYWRLE thread-safe for multiple clientsdscho2008-01-301-0/+2
| | | | | | | | ZYWRLE used a static buffer, which does not work too well if you have more than one client in a threaded server. Instead, we have the data in the client structure now. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* Add ZYWRLE server-side support (thanks Noriaki Yamazaki, Hitachi)dscho2008-01-291-0/+1
| | | | Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* Add CMake support (thanks to Christian Ehrlicher)dscho2008-01-292-0/+93
| | | | Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* rfbclient.h: use 'extern "C"' to make it convenient to include from C++dscho2007-04-061-0/+9
|
* rfb.h: Do not misplace guardsdscho2007-04-061-1/+3
| | | | This buglet made it impossible to double include rfb.h from C++.
* LibVNCClient: some users do not want to get whole-screen updates; introduce ↵dscho2007-02-011-0/+4
| | | | client->updateRect for that
* libvncclient: add GotCursorShape() and GotCopyRect(); x11vnc dep on libvncclientrunge2007-01-311-0/+6
|
* Move our rfbEncodings numbers out of the TightVNC range.runge2006-12-161-5/+5
|
* do not always include rfb/keysym.hdscho2006-09-121-1/+0
|
* make cut text handling using a hookdscho2006-09-111-2/+2
|
* KeyboardLedState Encoding Masks are now defined for portabilitysteven_carr2006-05-281-0/+18
|
* Permit auth.c to test major versionsteven_carr2006-05-161-0/+1
|
* Support sending TextChat messages back to the clientsteven_carr2006-05-151-0/+2
|
* Default to RFB 3.8, add command line option to specify the RFB version.steven_carr2006-05-152-1/+4
|
* The great UltraVNC Compatibility Commitsteven_carr2006-05-153-28/+126
|
* Server Capability Encodingssteven_carr2006-05-042-5/+43
| | | | | | | rfbEncodingSupportedEncodings - What encodings are supported? rfbEncodingSupportedMessages - What message types are supported? rfbEncodingServerIdentity - What is the servers version string? ie: "x11vnc: 0.8.1 lastmod: 2006-04-25 (LibVNCServer 0.9pre)"
* Client side support for PalmVNC/UltraVNC 'Server Side Scaling'steven_carr2006-05-041-0/+3
|
* KeyboardLedState should be placed in 'various protocol extensions'steven_carr2006-05-041-1/+1
|
* Client Independent Server Side Scaling is now supportedsteven_carr2006-05-031-0/+10
| | | | Both PalmVNC and UltraVNC SetScale messages are supported
* Ultra Encoding added. Tested against UltraVNC V1.01steven_carr2006-05-022-2/+23
|
* libvncclient: support changing of framebuffer size; make SDLvncviewer use itdscho2006-04-281-0/+2
|
* add KeyboardLedState extensiondscho2006-03-283-1/+15
|
* do not assume that KEYSYM_H guards X11's keysym.hdscho2006-03-011-2/+1
|
* add handleEventsEagerly flag (Thanks, Donald)dscho2006-02-281-1/+4
|
* Added method to get extension specific client datarohit_991292006-02-241-1/+1
|
* Added method to get extension specific client datarohit_991292006-02-241-0/+1
|
* add functions to unregister extensions/security typesdscho2006-02-221-0/+3
|
* introduce -deferptrupdate (thanks Dave)dscho2005-12-191-0/+7
|
* plug memory leaksdscho2005-12-071-0/+1
|
* fix deadlock from rfbReleaseExtensionIterator(), fix no libz/libjpeg ↵runge2005-11-252-1/+3
| | | | builds, disable tightvnc-filetransfer if no libpthread, add --without-pthread option, rm // comments, set NAME_MAX if not defined, x11vnc: throttle load if fb update requests not taking place.
* The PseudoEncoding extension code was getting silly:dscho2005-10-071-1/+1
| | | | | | | | | | | | | | | | | | | | If the client asked for an encoding, and no enabled extension handled it, LibVNCServer would walk through all extensions, and if they promised to handle the encoding, execute the extension's newClient() if it was not NULL. However, if newClient is not NULL, it will be called when a client connects, and if it returns TRUE, the extension will be enabled. Since all the state of the extension should be in the client data, there is no good reason why newClient should return FALSE the first time (thus not enabling the extension), but TRUE when called just before calling enablePseudoEncoding(). So in effect, the extension got enabled all the time, even if that was not necessary. The resolution is to pass a void** to enablePseudoEncoding. This has the further advantage that enablePseudoEncoding can remalloc() or free() the data without problems. Though keep in mind that if enablePseudoEncoding() is called on a not-yet-enabled extension, the passed data points to NULL.
* add an extension mechanism for LibVNCClient, modify the client data handlingdscho2005-10-061-1/+30
| | | | | so that more than one data structure can be attached, and add an example to speak the client part of the back channel.
* kill BackChannel and CustomClientMessage: the new extension technique makes ↵dscho2005-10-062-24/+0
| | | | these hooks obsolete
* provide a list of the pseudo encodings understood by the extensiondscho2005-10-061-1/+5
|
* add enablePseudoEncoding() to rfbProtocolExtensiondscho2005-10-031-0/+3
|
* This monster commit contains support for TightVNC's file transfer protocol.dscho2005-09-281-5/+15
| | | | Thank you very much, Rohit!
* Introduce generic protocol extension method. Deprecatedscho2005-09-271-1/+30
| | | | the processCustomClientMessage() method.
* Security is global. This was a misguided attempt to evade a global list.dscho2005-09-271-4/+1
| | | | I eventually saw the light and went with Rohit´s original approach.
* support VNC protocol version 3.7dscho2005-09-262-2/+41
|
* add definitions from other VNC implementationsdscho2005-06-061-0/+300
|
* make zlib and tight handling thread safe (static -> rfbClient)dscho2005-05-231-0/+44
|
* fix compilation for systems without socklen_tdscho2005-05-181-4/+0
|
* hide strict ansi stuff if not explicitely turned on; actually use the ↵dscho2005-05-181-0/+4
| | | | socklen_t test from configure.ac
* ANSIfy, fix some warnings from Linus' sparsedscho2005-05-153-4/+11
|