Previously all scrolling relied on "clicking" the up/down or left/right scroll buttons
which made it unprecise and to always scroll at the same speed.
Now we pass the scroll delta directly to the xorg input driver so the scroll is more responsinve and adaptive.
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
This is needed by vncserver which doesn't know which parameters are
boolean, and it cannot use the -Param=Value form as that isn't tolerated
by the Xorg code.
It seems like many of the X11 operations can end up with no pixels
actually changing. So instead of discovering and adding workarounds for
each individually we'll just check very region added if it's empty.
This allows Xvnc to build with xorg-server 1.20.7, which requires OS
layers to implement a ddxInputThreadInit function when configured with
--enable-input-thread (the default).
relevant xorg-server commit: e3f26605d85d987da434640f52646d728f1fe919
Ryan Kuba