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
Major restructuring of how streams work. Neither input nor output
streams are now blocking. This avoids stalling the rest of the client or
server when a peer is slow or unresponsive.
Note that this puts an extra burden on users of streams to make sure
they are allowed to do their work once the underlying transports are
ready (e.g. monitoring fds).
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 provides some basic rate limiting that will make it difficult
for an attacker to brute force passwords. Only relevant when the
blacklist is disabled as otherwise the attacker only gets a very
limited number of attempts.
Force queryConnection() to always call back to approveConnection()
rather than return special values. This makes the flow easier to
follow as it will be the same in all cases.
If an area recently changed then we can guess that it will most likely
change again very soon. In such a case it is meaningless to send a
lossless refresh as it will directly be overwritten. Keep track of
such areas and avoid refreshing them until we no longer see any
changes to them.
Improve the tracking of what cursor we've sent to the client to make
sure the initial cursor is sent properly. We previously tried to infer
this information based on if we've rendered a server side cursor or
not. This logic broke down if things triggered before we've sent the
first update to the client.
It was moved to the common code in f8e3b34c6, but it was unreliable
because the state could sometimes get out of sync. Push it back in
to Xvnc since it isn't necessarily something all servers will have.
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.
We now get notifications when the output buffer empties, and we
already caught incoming RTT pongs, meaning we can now react at the
proper time to retry a congested update rather than use a timer.
Variables were reused a bit too heavily and it was possible to get
the logic at a point where the server would try to render a cursor
where it wasn't needed, and the empty update rect would cause a
crash. Clear things up by introducing some more explicit variables.
Restructure Xvnc/libvnc.so code to avoid C++ header hacks
The internal Xorg headers are very incompatible with C++ and we've had
to resort to all kinds of hacks in order to include them in our C++
code. This approach isn't really viable long term so restructure things
so that we have a glue layer written in C that bridges the Xorg core
with the RFB classes.
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.
Use PixelBuffer objects as the interface for encoders and decoders
This avoid a lot of unnecessary middle men. This also pushes the
responsibility for pixel format conversion into the encoders and
decoders. The new bufferFromBuffer() is used for direct conversion,
rather than PixelTransformer/TransImageGetter.
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.
We were not handling the "sync next" fence properly as we sent the response
right after we got the request (instead of waiting for the next command).
This created a race where we could lose pixel format sync between the client
and the server.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4943 3789f03b-4d11-0410-bbf8-ca57d06f2519
Make the comparing update tracker a bit more flexible. It can now be in an
"auto" state where it will be enabled until we deem that the client is better
of without it (currently triggered by explicitly stating a low compression
level).
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4809 3789f03b-4d11-0410-bbf8-ca57d06f2519
Clean up the interface for VNCSConnectionST. Entry points are more apparent
and the data flow is now more strictly aimed towards this connection class.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4771 3789f03b-4d11-0410-bbf8-ca57d06f2519
Don't try to push out another update if the socket is already full. This
avoids stalling the entire server because of one slow client.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4737 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