Add support for notifying clients about pointer movements
This change adds support for the VMware Mouse Position
pseudo-encoding[1], which is used to notify VNC clients when X11 clients
call `XWarpPointer()`[2]. This function is called by SDL (and other
similar libraries) when they detect that the server does not support
native relative motion, like some RFB clients.
With this, RFB clients can choose to adjust the local cursor position
under certain circumstances to match what the server has set. For
instance, if pointer lock has been enabled on the client's machine and
the cursor is not being drawn locally, the local position of the cursor
is irrelevant, so the RFB client can use what the server sends as the
canonical absolute position of the cursor. This ultimately enables the
possibility of games (especially FPS games) to behave how users expect
(if the clients implement the corresponding change).
Part of: #619
1: https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#vmware-cursor-position-pseudo-encoding
2: https://tronche.com/gui/x/xlib/input/XWarpPointer.html
3: https://hg.libsdl.org/SDL/file/28e3b60e2131/src/events/SDL_mouse.c#l804
Implements support in both client and server for the extended
clipboard format first seen in UltraVNC. Currently only implements
text handling, but that is still an improvement as it extends the
clipboard from ISO 8859-1 to full Unicode.
We now filter incoming data, which means we can start assuming the
clipboard data is always null terminated. This allows us to clean
up a lot of the internal handling.
Require all SMsgWriter caller to check capabilities
Make the API consisitent by requiring the caller to check what the client
supports before calling any of the write* functions. This avoids the
confusion that the functions might not always do anything.
This is what the protocol requires, rather than sending what the
client specified in the request. This should be the same in practice
except for failures and possibly some races.
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.
Clang doesn't like when struct and class are used to refer
to the same thing interchangeably.
Fixes all instances of:
In file included from /home/shade/dev/tigervnc/common/rfb/CConnection.cxx:29:
In file included from /home/shade/dev/tigervnc/common/rfb/CConnection.h:28:
/home/shade/dev/tigervnc/common/rfb/DecodeManager.h:35:3: error: class 'Exception' was previously declared as a struct [-Werror,-Wmismatched-tags]
class Exception;
^
/home/shade/dev/tigervnc/common/rdr/Exception.h:32:10: note: previous use is here
struct Exception {
^
/home/shade/dev/tigervnc/common/rfb/DecodeManager.h:35:3: note: did you mean struct here?
class Exception;
^~~~~
struct
/home/shade/dev/tigervnc/common/rfb/DecodeManager.h:43:3: error: class 'Rect' was previously declared as a struct [-Werror,-Wmismatched-tags]
class Rect;
^
/home/shade/dev/tigervnc/common/rfb/Rect.h:68:10: note: previous use is here
struct Rect {
^
/home/shade/dev/tigervnc/common/rfb/DecodeManager.h:43:3: note: did you mean struct here?
class Rect;
^~~~~
struct
Move image encoding logic into a central EncodeManager class
This allows us to apply a lot more server logic
independently of which encoder is in use.
Most of this class are things moved over from the
Tight encoder.
Encoders/decoders should track the connection object
The connection object is a much more appropriate object for the
decoders and encoders to keep track of. Besides the streams, it also
contains state like connection parameters.
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.
Further optimizations to the Tight encoder to eliminate getImage() overhead. The encoder now directly accesses the framebuffer for solid rectangle computation, JPEG encoding, and color counting (if pixel translation is not required.) Also moved everything in tightEncode.h into the TightEncoder class to eliminate all of the static mess (this will be important later on if we decide to multi-thread the encoder.)
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
Make sure we send any modifications to the desktop layout in a message that
does not modify the framebuffer data. This is required to make sure we have
a valid state on the client as it drops the framebuffer when it recieves a
framebuffer dimension change.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3787 3789f03b-4d11-0410-bbf8-ca57d06f2519
It has some warts, but should be feature complete. Most of the magic happens
in the desktop class though.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3713 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
Implemented support for DesktopName pseudo encoding, which allows
updating the desktop name on the fly.
Tested in ThinLinc since 2008-01-07.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3549 3789f03b-4d11-0410-bbf8-ca57d06f2519
lhchavez
Pierre Ossman
Steve Kondik
DRC
Peter Åstrand
Constantin Kaplinsky