summaryrefslogtreecommitdiffstats
path: root/rfb
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* socketInitDone -> socketStatedscho2005-05-071-1/+11
|
* do the in_addr_t stuff correctly...dscho2005-03-071-0/+4
|
* add '-listen ipaddr' optionrunge2005-03-051-2/+4
|
* implemented Floyd-Steinberg dither in order to rfbMakeMaskFromAlphaSourcedscho2005-01-211-0/+1
|
* pointerClient was still static.dscho2005-01-181-48/+10
| | | | | | | | | | | | | | | | | | | | | | do not make requestedRegion empty without reason. the cursor handling for clients which don't handle CursorShape updates was completely broken. It originally was very complicated for performance reasons, however, in most cases it made performance even worse, because at idle times there was way too much checking going on, and furthermore, sometimes unnecessary updates were inevitable. The code now is much more elegant: the ClientRec structure knows exactly where it last painted the cursor, and the ScreenInfo structure knows where the cursor shall be. As a consequence there is no more rfbDrawCursor()/rfbUndrawCursor(), no more dontSendFramebufferUpdate, and no more isCursorDrawn. It is now possible to have clients which understand CursorShape updates and clients which don't at the same time. rfbSetCursor no longer has the option freeOld; this is obsolete, as the cursor structure knows what to free and what not.
* add convenience function to clip using x2,y2 instead of w,hdscho2005-01-181-0/+3
|
* add cursor alphablending to rfb.h cursor.c, x11vnc -alphablend -snapfb etc..runge2005-01-161-0/+2
|
* return value of rfbProcessEvents tells if an update was pendingdscho2005-01-141-2/+3
|
* add hook to allow for custom client messagesdscho2005-01-031-0/+5
|