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
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.
Do a proper cleanup when one of the termination timeouts trigger
rather than just exiting on the spot. This makes sure we don't leave
stray stuff around, e.g. unix socket files.
This makes VNCServer a sufficiently complete interface that callers
don't need to know about the specific implementation (VNCServerST
currently). And assuming that all servers will use sockets is not
that outrageous.
Removed the last parts of VNCSConnectionST's back door in to
VNCServerST and let the parent class fully handle coordination of
clients, and access to the desktop.
There are some cases where the server state will not automatically
be updated on a change. A prominent one is when only RFB attributes
were changes (e.g. the screen ID) but nothing else. In that case
there is no actual change in the X server, so it never sends any
notification about change back to us.
Change Xserver screen through libXrandr. For complex configurations,
all outputs must have corresponding size modes. As a special case, if
the client requests a single screen with an odd size (for example when
adjusting the size of a non-fullscreen vncviewer), find a smaller
suitable mode, and reduce the framebuffer size as well.
Unset pixel buffer when x0vncserver client disconnects.
In XDesktop::start() we allocate pixel buffer and set it as the backend to the given VNCServer.
In XDesktop::stop() we deallocate the buffer, so we must unset it from the VNCServer as well.
Otherwise the VNCServer could try to access it and crash, for example in deferred update.