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.
This is required by the protocol so we should make sure it is
enforced. We are tolerant of clients that violate this though and
convert incoming clipboard data.
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.
Avoid direct access to the screen dimensions and layout so that we
can make sure it stays sane. This also makes sure the layout is
properly updated when we only get the screen dimensions from the
server.
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.
If client sent fence with some data, followed by fence with no data (length 0), the original fence data were freed, but the pointer kept pointing at them. Sending one more fence would attempt to free them again.
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.
Add support for TurboVNC pseudo-encodings and Grayscale JPEG compression so that, when a TurboVNC viewer is connected, the TigerVNC Server will behave exactly like the TurboVNC Server.
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
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
lhchavez
Pierre Ossman
Brian P. Hinz
Michal Srb
DRC
Peter Åstrand
Constantin Kaplinsky