Make arguments explicit in all message writer methods
Make sure all methods only write what is given as arguments, and
avoid side effects by getting data from parameter objects. This keeps
things readable in the calling code.
This adds the basic infrastructure and handshake for the QEMU
Extended Key Events extension. No viewer or server makes use of
the extra functionality yet though.
They are created in SConnection's and CConnection's constructors but never destroyed.
There is no reason for the indirection, so lets make them direct members.
A read-only client should not be allowed to kick out other clients.
It will be forced into shared mode, or refused the connection, depending
on the neverShared parameter.
Allow SSecurity to specify AccessRights for SConnection.
SConnection has AccessRights property that specifies what connected client can
do. Set this property to value given by SSecurity after successful
authentication. This way individual SSecurity subclasses can accept clients but
restrict their access.
Move preferred encoding tracking into a server object
Having it in ConnParams made the linker pull all the encoder objects
into vncviewer, making it larger than necessary and giving it extra
parameters in its help output that weren't relevant.
Gets rid of a loooot of code and complexity.
Colour map clients are still supported through an
automatically generated map, but we lose the ability to
develop a client or server that uses colour maps
internally.
Eliminate GCC signed/unsigned warnings related to encodings: The
encoding in the RFB protocol has always been signed, and signed values
are also used in the specification (ie DesktopName = -307 etc). In the
code, however, unsigned types were used in a number of places, but not
all, which causes warnings. This patch fixes the problem by switching
to signed values everywhere.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3968 3789f03b-4d11-0410-bbf8-ca57d06f2519
Remove the "video" feature and its associated custom JPEG handling.
Having the client specifiy the video region is conceptually wrong
and a problem like this should be handled by better encoding selection.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3635 3789f03b-4d11-0410-bbf8-ca57d06f2519
Removed support for continuous updates, a TightVNC-specific RFB protocol
extension. That extension used to send framebuffer updates continuously, not
waiting for clients' requests. However, it showed bad results with
low-bandwidth connections, due to lack of proper data flow control.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@2581 3789f03b-4d11-0410-bbf8-ca57d06f2519
Initial implementation of continuous updates in the server code. This code does not handle framebuffer size changes properly yet. Also, the server does not send the client EndOfContinuousUpdates message yet (documented in doc/rfbproto.tex).
Reverted the changes appeared in revisions 2173,2181. We better always send the "security result" message in the protocol version 3.8, even after an empty list of authentication capabilities.
Corrected support for TightVNC extensions - always sending authentication capability list even when authentication is not required. This may be incompatible with certain TightVNC viewers but this is the way to allow "no authentication" AND prompting local user to accept/reject incoming connection.
Implemented support for TightVNC protocol extensions in the server code. This version has one incompatibility with TightVNC 1.3.x viewers - such viewers would not be able to connect without authentication. This will be fixed in the nearest time.
Pierre Ossman
Michal Srb
Henrik Andersson
Adam Tkac
Peter Åstrand
Constantin Kaplinsky