The normal logic does not work due to Wayland not supporting mouse warp.
We use a simple logic that works for the desktop with 1:1 mouse patch and
require capture mode for all other cases.
=================================================================
==7680==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000ec010 at pc 0x5622fcf9f386 bp 0x7f36084ff680 sp 0x7f36084ff678
WRITE of size 4 at 0x6020000ec010 thread T1
#0 0x5622fcf9f385 in clipboardRequest /code/LookingGlass/client/src/main.c:707
#1 0x5622fd0036c9 in wayland_cb_notice /code/LookingGlass/client/clipboards/Wayland/src/wayland.c:521
#2 0x5622fcf9f4dc in spiceClipboardNotice /code/LookingGlass/client/src/main.c:724
#3 0x5622fcfc4d59 in spice_agent_process /code/LookingGlass/repos/PureSpice/src/spice.c:1106
#4 0x5622fcfc16d6 in spice_on_main_channel_read /code/LookingGlass/repos/PureSpice/src/spice.c:655
#5 0x5622fcfbee4f in spice_process /code/LookingGlass/repos/PureSpice/src/spice.c:361
#6 0x5622fcf9e3a2 in spiceThread /code/LookingGlass/client/src/main.c:598
#7 0x5622fd006b5e in threadWrapper /code/LookingGlass/common/src/platform/linux/thread.c:39
#8 0x7f3614b2bf26 in start_thread /build/glibc-WZtAaN/glibc-2.30/nptl/pthread_create.c:479
#9 0x7f3614a4c2ee in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xfd2ee)
0x6020000ec011 is located 0 bytes to the right of 1-byte region [0x6020000ec010,0x6020000ec011)
allocated by thread T1 here:
#0 0x7f36156f9628 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x107628)
#1 0x5622fcf9f33f in clipboardRequest /code/LookingGlass/client/src/main.c:705
#2 0x5622fd0036c9 in wayland_cb_notice /code/LookingGlass/client/clipboards/Wayland/src/wayland.c:521
#3 0x5622fcf9f4dc in spiceClipboardNotice /code/LookingGlass/client/src/main.c:724
#4 0x5622fcfc4d59 in spice_agent_process /code/LookingGlass/repos/PureSpice/src/spice.c:1106
#5 0x5622fcfc16d6 in spice_on_main_channel_read /code/LookingGlass/repos/PureSpice/src/spice.c:655
#6 0x5622fcfbee4f in spice_process /code/LookingGlass/repos/PureSpice/src/spice.c:361
#7 0x5622fcf9e3a2 in spiceThread /code/LookingGlass/client/src/main.c:598
#8 0x5622fd006b5e in threadWrapper /code/LookingGlass/common/src/platform/linux/thread.c:39
#9 0x7f3614b2bf26 in start_thread /build/glibc-WZtAaN/glibc-2.30/nptl/pthread_create.c:479
Thread T1 created by T0 here:
#0 0x7f361562b9b2 in pthread_create (/lib/x86_64-linux-gnu/libasan.so.5+0x399b2)
#1 0x5622fd006cd0 in lgCreateThread /code/LookingGlass/common/src/platform/linux/thread.c:50
#2 0x5622fcfa5a7d in lg_run /code/LookingGlass/client/src/main.c:1615
#3 0x5622fcface28 in main /code/LookingGlass/client/src/main.c:2035
#4 0x7f3614975e0a in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: heap-buffer-overflow /code/LookingGlass/client/src/main.c:707 in clipboardRequest
Shadow bytes around the buggy address:
0x0c04800157b0: fa fa 00 00 fa fa fd fa fa fa fd fa fa fa fd fd
0x0c04800157c0: fa fa fd fd fa fa fd fa fa fa 00 fa fa fa 00 fa
0x0c04800157d0: fa fa 00 fa fa fa fd fa fa fa fd fd fa fa fa fa
0x0c04800157e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c04800157f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c0480015800: fa fa[01]fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0480015810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0480015820: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0480015830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0480015840: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0480015850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==7680==ABORTING
On Wayland, SDL_WINDOWEVENT_CLOSE is sent even when exiting with keyboard
shortcuts. This meant that the client is still closed even with -Q.
We now swallow SDL_WINDOWEVENT_CLOSE if the cursor is inside the VM. This
should prevent keyboard shortcuts from closing the client, while still
allowing the window to be closed by clicking X with the mouse per #138.
Rapid movements in games can cause large detas that may cause the client
to allow the mouse to exit when this is not desired. This change
attempts to limit this by ignoring movements large movements when using
this mode.
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!
While using the RAW movement data sounds like a good idea the user
experience is quite bad as the mouse acceleration between host and guest
changes entering capture mode. This change alters this behaviour to use
the values after processing by the X server while retaining the simpler
code path for capture mode.
x11 serials are per server command, not per event, as such several
events may be processed by the server before a new event is received
causing the existing logic to fail. This changes the logic to check for
a larger serial instead of an exact match, and confirms the completion
of the warp by matching the target x/y.
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.
This fixes an issue where the warp to center could break as the user
moves their cursor slowly over one of the bottom or right edges of the
screen while it's letterboxed.
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.
DXGI DesktopDuplication does not send cursor positional updates when the
cursor is hidden, this happens when dragging a window around or when a
full screen application takes/hides the cursor. If this happened at the
same time as a resolution switch we don't know where the cursor really
is anymore.
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
Some setups (e.g. Wayland) have high precision scroll wheel input, such
that the y-delta on an event may exceed 1. In these cases, scrolling up
currently gets treated as scrolling down.
This commit changes the checks to use > 0 rather than == 1.
This is the approach suggested in
https://wiki.libsdl.org/SDL_MouseWheelEvent.
This commit makes Looking Glass always use the OpenGL renderer when
running on Wayland. The EGL renderer is broken on Wayland and can't
reasonably be fixed until SDL is dropped entirely (as per
https://github.com/gnif/LookingGlass/issues/306).
Until that time, the OpenGL renderer provides a much better
Wayland-native experience.
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.
eglSwapBuffers is allowed to block when called with a nonzero interval
parameter. On Wayland, Mesa will block until a frame callback arrives.
If an application is not visible, a compositor is free to not schedule
frame callbacks (in order to save CPU time rendering something that is
entirely invisible).
Currently, starting Looking Glass from a terminal, hiding it
entirely, and sending ^C will cause Looking Glass to hang joining the
render thread until the window is made visible again.
Calling eglDestroySurface is insufficient to unblock eglSwapBuffers, as
it attempts to grab the same underlying mutex.
Instead, this commit makes it so that we pass a 0 interval to
eglSwapBuffers when running on Wayland, such that we don't block waiting
for a frame callback. This is not entirely ideal as it *does* mean
Looking Glass submits buffers while hidden, but it seems better than
hanging on exit.
It also forces opengl:vsync and egl:vsync flags to off when running on
Wayland, as they are meaningless there.
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.
Since we only ever use offset movements as SPICE doesn't properly
support absolute x/y positional information without a virtual tablet
device (which breaks relative mode needed for capture), just always run
in this mode. This fixes an issue when the spice guest tools are
installed and the mouse fails to work when not captured.
The texture buffer may still be in use if we try to re-map it
immediately, instead only map when we need it mapped, and unmap
immediately after advancing the offset allowing the render thread to
continue while the unmap operation occurs
This is a major change to how the LG client performs it's updates. In
the past LG would operate a fixed FPS regardless of incoming update
speed and/or frequency. This change allows LG to dynamically increase
it's FPS in order to better sync with the guest as it's rate changes.
