This change alters the small square dot cursor to a more visible 16x16
cursor for X11. A new option `spice:largeDotCursor` can be set to use an
alternative 32x32 cursor for the vision impaired.
This commit adds an interface to the X11 display server code to support
various window manage specific features, such as in this case, the i3
global full screen toggle.
This feature specifically uses the i3 IPC to cause looking glass to go
full screen across all monitors if the new option `i3:globalFullScreen`
is enabled.
According to Erik @ NVidia the open source NVidia driver will not
create a EGLImage from a DMABUF if the target is not
GL_TEXTURE_EXTERNAL_OES. This change set converts the dmabuf texture
from GL_TEXTURE_2D to GL_TEXTURE_EXTERNAL_OES and at runtime performs a
global search & replace on fragment shaders as needed to remain
compatible, replacing `sampler2D` with `samplerExternalOES`.
Ref: https://github.com/NVIDIA/open-gpu-kernel-modules/discussions/243#discussioncomment-3283415
If the cursor was grabbed the window the cursor moves over when it is
ungrabbed will recieve an EnterNotify event with the mode of
NotifyUngrab, unfortunatly some window manages such as i3 will ignore
this message and as such focus follows mouse will not function
correctly. This patch injects a normal EnterNotify to work around this
issue.
This fixes a rounding issue on certain hardware (NVidia) which actually
implement mediump as half precision (16-bit) float. It's safe to assume
`highp` is available as if the GPU does not support it, then the shader
compiler will try to find a lower precision that is supported by the GPU
This is rare and I'm not sure what causes it, but PipeWire sometimes uses a
larger period size than requested for no obvious reason (e.g., we could
request a period size of 512, but PipeWire uses 2048 anyway). This causes
us to stay in a permanent state of underrunning because the target latency
is too low.
With this change, we use the actual device period in the target latency
calculation if it is larger than the expected maximum. We may still get
some glitches at the beginning of playback (because the startup latency is
based upon the expected maximum period size), but it will recover after a
few seconds as it adjusts to the new target latency.
This fixes the following crash when attempt to toggle capture at the
right after closing the overlay:
zwp_pointer_constraints_v1@12: error 1: a pointer constraint with a wl_pointer of the same wl_seat is already on this surface
There is no action to be taken by the Looking Glass client, but a
handler needs to exist as certain other Wayland clients chooses to
send this message for copy-paste operations despite the fact it's
supposed to be used for drag-and-drop negotiation.
This commit makes it show a prettier error message when no display
server is available, including the display servers compiled. This
replaces the old assert.
Example output:
[E] 572277145932 main.c:1167 | lg_run | No display servers available, tried:
[E] 572277145934 main.c:1169 | lg_run | * Wayland
[E] 572277145935 main.c:1169 | lg_run | * X11
Certain window managers give us a scale before it gives us a size.
This commit makes the Wayland backend avoid passing a zero size to
wp_viewport_set_source, which is a protocol error.
The Wayland display server has a graph for presentation times, but the
backend shuts down after the overlays, so calling
overlayGraph_unregister causes memory corruption. We can avoid this
problem by making unregister a noop after all graphs have been freed.
This is safe because updating the graph doesn't use the graph handle:
instead you update the ringbuffer which is owned by the user.
A failure to connect to spice would cause LG to exit late, this adds a
startup condition that prevents the LG initialization to complete until
the spice connection has been established.
This brings nanosvg into the project for SVG loading and rendering.
Unfortunatly we can not at this time use a submodule for this project
until https://github.com/memononen/nanosvg/pull/214 is merged.
Profiling shows that a considerable amount of time is spent in
glBindBuffer and glBufferSubData when the damage rects are updated.
Since the amount of data here is quite small it's far faster to check if
it's different then to just blindly overwrite the buffer on each call.
Profiled on an Intel CPU with UHD P630 Graphics using magic-trace
