This will not try the captured-event shenanigans to emulate grab
behavior, instead relying on event delivery being influenced by
other grab mechanisms.
While at it, improve handling of additional touchpoints by
cancelling the click action right away, as the differences in
event handling make this unwanted behavior surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2024>
By default, the pan action performs matrix translations on the
child widget. Nobody wants that (or, nobody wants *just* that).
It's cleaner not to mix mechanism and effect in ClutterGestureAction
subclasses, so drop this base implementation, and change the signal
accumulator so it's more similar to event signals (not that it's
used any longer, anyway).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2024>
Mutter already calculates and tracks the damage rectangles to redraw
only areas of the screen that change since the last time a buffer was
used.
This patch extends this by using the EGL_KHR_partial_update extension to
inform the GPU in advance that only those areas will be changed, which
may allow for further optimization.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2023>
Add support for a cogl function to set the damage_region on an onscreen
framebuffer.
The goal of this is to enable using the EGL_KHR_partial_update extension
which can potentially reduce memory bandwidth usage by some GPUs,
particularly on embedded GPUs that operate on a tiling rendering model.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2023>
Defining valid values makes
1. changing settings less error prone
2. sure they are discoverable.
This does reset the values once on update, but fortunately does *not*
change the way to set the values. Thus e.g. enabling fractional scaling
via terminal command still works as before and internet guides stay valid.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1961>
This will make clients immediately aware of the output disappearing,
while still allowing for a grace period of 10 seconds for attempting to
bind to it before it turning into a protocol error. This API added as
part of wayland 1.18.
This requires us to not add the output resource to the output resource
list, if the output was made inert. This effectively makes the resource
useless, but that is harmless, since shortly after, the client will
clean it up anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
This will be crucial when we start to remove the global directly when an
output is removed, as that means Xwayland might have removed the output
before we managed to get our queries in.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
We setup Xwayland in an early phase of the X11 display, before we had a
MetaX11Display, and teared down in a couple of places happening when
tearing down the Xwayland integration if the X server died or
terminated. It was a bit hard to follow what happened and when it
happened. Attempt to clean this up a bit, with things being structured
as follows:
* Early during X11 display connection setup, only setup the rudimentary
X11 hooks, being the libX11 error callbacks, and adding the local
user to XHost.
* Move "initialize Xwayland component" code to a new
'x11-display-setup' signal handler. Things setup here are cleaned up
in the 'x11-display-closing' handler.
* Connect to 'x11-display-setup' and 'x11-display-closing' up front,
and stay connected to these two.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
This old handling of session files looked on ~/.mutter, which has
been unused and unsupported for a long time. It also had paths were
the GError was leaked. Fix both by dropping the legacy code, and
falling back to the common error paths.
CID: #1502682
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2061>
This warning is actually dead code, since should_be_mapped and
must_be_realized are always set to the same value, so it does not
make sense to check for "a && !b".
Turn this into an assert so we avoid the dead branch, but do not
remove the variable duplication so the more aptly named variable
is used where it belongs, for clarity.
CID: #1506254
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2061>
When grabbing the devices, there's no error paths that would quit
late enough that both pointer and keyboard would need ungrabbing,
so the keyboard checks were dead code.
Fix this by dropping the boolean variable checks, and adding goto
labels to unroll the operation properly at every stage.
CID: #1418254
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2061>
The monitor orientation tests do a lot of things in sequence. Replace
some of the comments with g_test_message() so that the log from a failed
test gives us a better idea of how far we got.
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2049>
Previously, we were waiting up to 300ms for the signal, then proceeding
anyway. However, 300ms is not necessarily long enough to wait on an
autobuilder that might be heavily loaded, particularly if it's a non-x86
with different performance characteristics.
Conversely, if mutter responds to the D-Bus signal from the mock sensor
before we have connected to the signal, then we cannot expect to receive
the signal - it was already emitted, but we missed it. In this case, we
need to avoid waiting.
One remaining use of wait_for_orientation_changes() that would previously
always have timed out was in
meta_test_orientation_manager_has_accelerometer(), which does not
actually expect to see an orientation-changed signal. Make this wait
for the accelerometer to be detected instead.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/1967
Bug-Debian: https://bugs.debian.org/995929
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2049>
When we use gbm together with the NVIDIA driver, we want the EGL/Vulkan
clients to do the same, instead of using the EGLStream paths. To achieve
that, make sure to only initialize the EGLStream controller when we
didn't end up using gbm as the renderer backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2052>
This switches the order of what renderer mode is tried first, so that
the gbm renderer mode is preferred on an NVIDIA driver where it is
supported.
We fall back to still try the EGLDevice renderer mode if the created gbm
renderer is not hardware accelerated.
The last fallback is still to use the gbm renderer, even if it is not
hardware accelerated, as this is needed when hardware acceleration isn't
available at all. The original reason for the old order was due to the
fact that a gbm renderer without hardware acceleration would succeed
even on NVIDIA driver that didn't support gbm.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2051>
