One of the major issues with the old tracking code is a data race
between the cursor thread updating g_cursor.guest and the
app_handleMouseBasic function. Specifically, the latter may have
sent mouse input via spice that has not been processed by the guest
and updated g_cursor.guest, but the guest may overwrite g_cursor.guest
to a previous state before the input is processed. This causes some
movements to be doubled. Eventually, the cursor positions will
synchronize, but this nevertheless causes a lot of jitter.
In this commit, we introduce a new field g_cursor.projected, which
is unambiguously the position of the cursor after taking into account
all the input already sent via spice. This is synced up to the guest
cursor upon entering the window and when the host restarts. Afterwards,
all mouse movements will be based on this position. This eliminates
all cursor jitter as far as I could tell.
Also, the cursor is now synced to the host position when exiting
capture mode.
A downside of this commit is that if the 1:1 movement patch is not
correctly applied, the cursor position would be wildly off instead
of simply jittering, but that is an unsupported configuration and
should not matter.
Also unsupported is when an application in guest moves the cursor
programmatically and bypassing spice. When using those applications,
capture mode must be on. Before this commit, we try to move the guest
cursor back to where it should be, but it's inherently fragile and
may lead to scenarios such as wild movements in first-person shooters.
If the guest has it's output rotated (ie, landscape) we must rotate and
translate the pointer draw location, as well as all the translations of
cursor coordinate spaces based on the rotation, along with any local
rotations that may also be applied.
This new mode if enabled (disabled by default) will cause the client to
attempt to hold onto the mouse when a title/game has it captured in the
guest. This is best effort and is not a replacement for full capture
mode.
This option allows those that want it (gamers) to bypass all X11 mouse
acceleration and smoothing giving true 1:1 input to the guest while in
capture mode. Note: only supported for X11!
Previously only up to two pending warp requests were possible, this
changes this so that additional warps can be queued if the cursor's
delta has moved more then 50px between each warp request.
The old code also had an error where it would null out any additional
movement since the warp was requested, but before it was processed, this
has been corrected.
As X11 is a server/client protocol, issuing commands such as
XWarpPointer do not happen immediately, as such we need to identify when
the warp is complete to know to null out the movement. To do this we
track each warp issued and look for it's completion in the event filter.
As some events come in via XInput2 we need to also make use of this
instead of just relying on MotionNotify, as such the support has been
implemented for XI_Motion events.
If active this will prevent the client from sending keyboard events for
the windows key. The idea is to allow people to keep the windows key
bound to their WMs default action without causing the Windows start menu
to open
This change allows us to look for and filter out the warp completion
event as we can obtain and use the serial number of the warp request to
do so. This is far more elegant then the x/y match that we were doing
prior.
Note: This only works with the KVMFR kernel module in a VM->VM
configuration. If this causes issues it can be disabled with the new
option `app:allowDMA`
This new option, when enabled (the default) enables cursor movements to
trigger frame updates in the client, improving responsiveness at the
cost of increased FPS while the mouse is moving around.
This commit bumps the KVMFR protocol version as it adds additional
hotspot x & y fields to the KVMFRCursor struct. This corrects the issue
of invalid alignment of the local mouse when the shape has an offset
such as the 'I' beam.
This patch increases the default cursor and frame polling interval from
1us to 1000us which for most use cases should be more then fast enough.
It also adds two new configuration options to adjust these should it be
required:
* app:cursorPollInterval
* app:framePollInterval
