If the renderer fails to start it sets the run state to stopped, having
lgInit where it was causes this to be reset to running triggering
invalid usage of g_state.lgmp.
Under some circumstances, Looking Glass can hang when SIGINT'd, for
instance, if it's stuck waiting on spice I/O that won't complete because
the guest is misbehaving.
This commit provides an escape hatch for such cases, so one doesn't have
to reach for `kill -9 $(pidof looking-glass-client)`.
We are forced to use accelerated movement in regular mode as that is how the
host machine cursor moves and we want the cursors to line up (since Wayland
cannot do warps). To avoid a change in sensitivity when toggling capture
mode on/off, we should use accelerated deltas for capture mode as well,
unless the user explicitly asks for raw input with input:rawMouse.
It does not make sense to accumulate fractional error in non-capture mode
as you know exactly where the cursor is supposed to be, at least on Wayland.
On Wayland, we base movements on the current guest position and desired
target position, and the accumulated errors only skew our movements.
Build failed with _FORTIFY_SOURCE enabled because the compiler couldn't
ensure the switch statements didn't hit the default arm and thus wouldn't
define the variables. Adding a statically failing assert makes sure that
all code paths either define the variables or fail early.
$ cd client
$ env CFLAGS='-O1 -D_FORTIFY_SOURCE=1' cmake -B build/
$ make -C build
[...]
client/renderers/EGL/egl.c: In function ‘egl_calc_mouse_size’:
client/renderers/EGL/egl.c:299:36: error: ‘h’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
299 | (this->mouseHeight * (1.0f / h)) * this->scaleY
| ~~~~~~^~~~
When using the meta resize feautre the cursor is over the client window,
and as such the application continues to receive motion events. This
causes the window size to spaz out.
As the screen output rotation can be changed on the fly, if it has been
rotated to 90 or 270 the nearest flag will be incorrect, so we perform
this check here and override the provided value.
This is an ugly hack for now that will get us over the line for Beta 3,
after which will need to be addressed and people will need to be
informed that their configured escape key will have changed.
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.
It appears that Wayland pointer motion handlers are called even when relative
mouse mode is enabled. The events they generate break first-person games.
This commit disables those handlers when relative mouse is enabled.
Unless the corresponding mouse down event was on our surface, we should
not be receiving the mouse up.
This is always the case on Wayland. On some other platforms,
SDL_CaptureMouse can be used to obtain input that happens outside the
Looking Glass surface, but Looking Glass does not make use of that
function.
We may want to process a mouse up if the corresponding mouse down
initiated a drag (e.g., of a window) that was released slightly outside
of the Looking Glass surface. Previously, Looking Glass would ignore the
mouse up, and the guest would be confused into thinking the button had
never been released, not ending the drag.
zwp_relative_pointer_manager_v1 and zwp_pointer_constraints_v1 are
supported by GNOME/KDE/sway (and most other compositors), but they are
not a required part of the protocol.
Some users also run software in one-off nested compositors like cage[0]
for an extra layer of isolation; cage, at least, does not support
pointer captures.
This commit makes Looking Glass warn when an optional protocol is
unsupported, and fail if a required one is missing. Pointer grab paths
have a new guard against the aforementioned protocols being missing.
[0]: https://github.com/Hjdskes/cage
We are actually getting mouse events directly from Wayland instead of going
through SDL, so we call app_updateCursorPos in pointer motion handlers and
swallow the SDL event.
Also removed parameters for app_handleMouseBasic as it relies exclusively on
absolute positions provided by app_updateCursorPos. Wayland does not give
you relative movements at all unless grabbed and passing absolute movements
is semantically incorrect.
Note that when the cursor is grabbed, movements are handled entirely through
relativePointerMotionHandler in wayland.c and does not go through
app_handleMouseBasic at all.
If the guest cursor state & position is unknown we can not rely on the
information to detect edge crossings. As such only allow cursor input if
LG is operating in capture mode.
Platforms such as Wayland have no abillity to warp the cursor, as such
can not operate in an always relative mode. This property allows
platforms to report the lack of warp support and prevent LG from
grabbing the pointer.
Some platforms such as Wayland need to set environment vairables before
SDL is initialized, as such this change detects the display server
before SDL has started and calls the new `earlyInit` method providing
the implementation an opportunity to set things up.
When capture mode is set if the cursor is not already in the view area
we need to force it to the state it would be if it were in view as
capture mode overrides all.
The pointer may not yet be in the view area so we should defer drawing
it until the mouse move handler determines that it's inside the view
area and turn it on itself.
As LG always operates in relitive mode, the actual pointer grab/ungrab
is managed by the move handler, as such setGrabQuiet should not alter
the grab/ungrab state of the local pointer.
The prototype for abs is int abs (int n), which implicitly casts floating
point values to integers. The correct function is fabs.
This commit allows the client to compile under clang.
gcc -Wimplicit-fallthrough only detects comments if they are immediately
preceded before the next label. Braces stops it from recognizing the
fallthrough comment.
-Wno-sign-compare is used to suppress warnings related to comparing signed
values with unsigned ones. It's too pedantic.
-Wunused-parameter is also too pedantic, especially since all parameters
have to be named in C.
Otherwise, -Wextra lets us catch bugs, such as x < 0 for unsigned x.
On gcc, we pass -Wimplicit-fallthrough=2 so it will recognize our fall
through comment.
This makes it a compile-time error to call a function that semantically
takes no parameters with a nonzero number of arguments.
Previously, such code would still compile, but risk blowing up the stack
if a compiler chose to use something other than caller-cleanup calling
conventions.
Copying rich text from the guest would be turned into plaintext on the client.
Prior to this change, this would be sent back to the guest, overwriting its
clipboard. This made it impossible to copy rich text inside the guest.
This commit detects such self-copies by checking if the receiver is the
current process, and rejecting it.
This prevents looking-glass-client from failing with an error message like:
error marshalling arguments for receive (signature sh): null value passed for arg 0
Error marshalling request: Invalid argument
When input:grabKeyboardOnFocus is set (default), entering capture mode grabs
the keyboard a second time. This commit makes the second grab a no-op on
Wayland to avoid a crash.
Previously, main.c would segfault at runtime if clipboards were disabled
via cmake flags, as the clipboards array would be empty but still
indexed during initialization.
Co-authored-by: Quantum <quantum2048@gmail.com>
Otherwise, a badly-behaving client causes Looking Glass to receive a
SIGPIPE during Wayland copy operations. Handle EPIPE at call-sites
instead.
Co-authored-by: Quantum <quantum2048@gmail.com>
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.
POSIX `send` is thread safe, to take advantage of this the code has been
changed to construct a contiguous buffer and perform the send in a
single operation preventing any risk of a race condition.
Only the main channel still requires an interlock as the VD agent
requires multiple sends to transmit a full buffer.
xinput2 is used to get touch interface events with the side effect of
consuming MotionNotify events which we use because of SDL2's inability
to correctly track the window size. Since we are not that intertested in
touch for our usecase, we just turn the events off again.
Returning -1 from a function with bool as return argument is the same as
returning true. If the channel is not connected, return false instead to
indicate the error.
[Why]
Recent versions of Mesa may have trouble with surface creation, resulting in
errors like:
egl.c:428 | egl_render_startup | Failed to create EGL surface (eglError: 0x300b)
[How]
Replace eglGetDisplay() with eglGetPlatformDisplay(). Requires EGL 1.5, but should
be supported with any desktop driver released in the past few years.
This changes the method of the memory copy from the host application to
the guest. Instead of performing a full copy from the capture device
into shared memory, and then flagging the new frame, we instead set a
write pointer, flag the client that there is a new frame and then copy
in chunks of 1024 bytes until the entire frame is copied. The client
upon seeing the new frame flag begins to poll at high frequency the
write pointer and upon each update copies as much as it can into the
texture.
This should improve latency but also slightly increase CPU usage on the
client due to the high frequency polling.
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
While it is recommended to use memory barriers when updating a buffer
like we are, since we double buffer it is unlikely we will corrupt a
prior frame, and even if we do since it's just texture data at worst
we might see a tear.
