One can add a wl_global filter to a wl_display instance, which can be
used to decide what clients should see what globals. This has so far
been used to limit a Xwayland specific protocol extension to only
Xwayland. In order to expand the logic about what globals are filtered
to what clients, introduce a filter manager and port the Xwayland
specific protocol filter to this new manager.
Tests are added, using a new dummy protocol, to ensure that filtering is
working as expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
It only tests indirect clients, i.e. not the subprocess part, so far,
but tests explicitly terminating by destroying the MetaWaylandClient
object, as well as the client self terminating and the signal being
emitted.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
This API creates a "client" then later sets up a wl_client and returns a
file descriptor some Wayland client can connect to. It's meant to be
used as a method other than WAYLAND_SOCKET and process launching, e.g.
passing a file descriptor via a D-Bus API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
There will be two kind of client instances, lets move fields that are
only relevant to the current way of operation in an anonymous struct to
keep things a bit separate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
On X11, the stage itself is backed by an XWindow, and moving the
input focus elsewhere will bypass any Clutter-level grabs.
This effectively allows newly opened windows to steal the focus
from gnome-shell itself, which is clearly undesirable. To prevent
that, only allow moving the X11 focus to a Window when no grab is
in place, just like commit 50e89e376 did for the stage focus.
But particularly the updating of x11_display->focus_xwindow is not
prevented. Since it's more consistent to the MetaDisplay/MetaX11Display
dual focus tracking and across Wayland/X11 backends, ensure the X11
input focus is actually set on the last focus Window after the
grabs are gone and windows became interactable again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2832>
This patch unfortunately results in situations where it is intended
that the focus change happens while a grab is present (e.g. Alt+tab
popup), resulting in confused focus state.
This commit is reverted in order to try a similar approach at a
different level.
This reverts commit 7531669b4f.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2832>
We used it to retrieve a Display, and convert between Atoms and
strings. We can just use the MetaX11Display's Display (It's the
same than GDK's anyways) and use XInternAtom/XGetAtomName for
these conversions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2836>
We didn't always set an implementation, when the foreign toplevel wasn't
found, and when the importer tried to set the parent-child relationship,
the implementation was missing and we'd crash in wl_closure_invoke() in
libwayland-server.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2834>
Windows that are decorated may get configure requests before
the frames client created a corresponding frame window and Mutter
reparented the window.
Since the configure request results in the buffer size being
used to update the window size and the window does not have a
buffer yet, these requests could mistakenly result in the client
window being given a minimal size.
In these situations, do not use the buffer size but the given
size. The window still has to undergo frame creation and
reparenting before being shown for the first time.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2588
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2605
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2808>
This used to be implicitly done by popups using a META_GRAB_OP_WAYLAND_POPUP
MetaDisplay grab. Since commit a8cd488c6f Wayland popups no longer do that,
so the keyboard focus was simply unset if a popup was destroyed while having
the keyboard focus.
Trigger a full input focus sync, so the correct MetaWaylandKeyboard focus
surface is looked up from the focused MetaWindow.
Fixes: a8cd488c6f - wayland: Drop redundant MetaDisplay grab op
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2833>
On one hand, this used to be handled generically in all the paths that
changed the MetaWaylandPointer focus surface, induced by user interaction
or not.
On the other hand, just listening for crossing events is not sufficient
since those also do happen programmatically. We must only listen to
crossing events that have a physical source device, meaning this was
created through user interaction.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/888
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2828>
For motion-induced crossing events, this will be the device that generated
the motion. For code-induced crossing events (e.g. grabs or actors disappearing)
this will be none.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2828>
On Wayland sessions, this handling is unnecessary and even prone
to confusion (e.g. crossing serials are only ignored in X11-exclusive
paths, so this handling competes directly with that in MetaWaylandPointer).
Avoid it entirely there, so MetaWaylandPointer can figure out
sloppy/mouse mode focus for all Wayland/Xwayland surfaces.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2828>
In GTK this is only used for GTK clipboard/DnD selections, and
finding out whether there is a compositing manager in charge.
In Mutter, we manage our own clipboard/DnD selections, and don't
perform any rendering through GTK in the Mutter process.
So there's no special reason to let these events go through GTK,
and (related to xwayland-on-demand?) there may be race conditions
in the handling of the second feature.
There's a chance this race condition may be in Mutter, but it
does not sound worth to chase this race condition when we can
let GTK ignore these events. And it does not make sense to "fix"
gtk3 for this Mutter-only condition, when we intend to eventually
avoid it.
So, take the easy path and ignore these events.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2617
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2831>
Marking the the depth/stencil as discarded before swapping buffers for
the screen signals the GPU that we don't need to keep them around for
the future.
This helps performance by reducing memory bandwidth usage in some GPUs
which may optimize to not write those buffers back to memory at all
after rendering, when they would just be cleared right after that
anyway.
It is not necessary to mark buffers as discarded after swapping buffers.
This should have no effect according to the spec (since that is going to
be followed by new rendering commands which make the buffer valid again)
and removing that has shown no impact in performance tests.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2091>
cogl_framebuffer_discard_buffers required that the color buffer is
passed, although users might want to discard e.g. just depth and/or
stencil buffers.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2091>
The first monitor in stacking tests is the primary monitor but that
doesn't have to stay this way forever. Instead of special casing the
name "primary" to refer to whatever monitor happens to be the primary
monitor, we add an `assert_primary_monitor` command to verify that the
monitor that should be the primary monitor actually is.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2748>
New add_monitor command for adding secondary monitors. Support setting
the workspaces-only-on-primary preference.
The stacking test tests the focus and stacking for multiple monitors
with workspaces-only-on-primary=true. The default_focus changes
previously broke this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2748>
The X-GNOME-Bugzilla-* entries in the desktop file were for use by
bug-buddy, a GNOME 2 technology that's been gone for over a decade.
These entries are obsolete and the desktop file can be removed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2621>
bind_output() creates output interface resource, but does not
set implementation for it when wayland_output->monitor is NULL.
However, when the wayland library is running wl_closure_invoke(),
it expects the implementation to be non-NULL, and if not, it just
segfaults mutter by NULL pointer dereference.
This commit tries to address this issue by setting an implementation
when wayland_output->monitor is NULL. This could help prevent crash
when resuming from suspend or hotplugging displays.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2570
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2827>
The order of dependencies influences the order of -L arguments to gcc/ld,
we should put our private library first, so that introspection prefers
looking up libraries in private paths than public ones.
This could bring problems in API updates of the libmutter-test library,
since introspection would still prefer the old installed one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2826>
ClutterActions now no longer receive their events via
clutter_actor_event(), instead they get special treatment by the stage
now. Make the MetaGestureTracker work with this and stop emitting events
directly to Clutter via clutter_actor_event(), but instead let them get
through to Clutter (but still not to Wayland).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
Since the last commit, ClutterStage automatically cancels an implicit
grab (including all its ClutterActions) when a conflicting ClutterGrab
appears.
This means we no longer have to look out for GRAB_NOTIFY crossings in
ClutterGestureAction and can instead depend on the sequence_cancelled()
vfunc for this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
A ClutterGrab takes precedence over implicit grabs, so when one happens,
let's check which part of the implicit grab tree is inside the new
ClutterGrab. Cancel and remove the parts which aren't, and if nothing
is in there anymore, cancel the whole implicit grab.
Emitting crossing events correctly here is getting quite tricky:
- When the implicit grab didn't get cancelled by the ClutterGrab, we
simply want to emit all GRAB_NOTIFY crossings to the implicit grab, as
we do with all other crossings.
- When the implicit grab did get cancelled and the new ClutterGrab wants
to emit ENTER crossings, we want those to be emitted to the actual
targets, so cancel the implicit grab before emission.
- In the last case where the implicit grab did get cancelled and the new
ClutterGrab wants to emit LEAVE crossings, those should be emitted to
the implicit grab again, so we cancel the grab only after the emission
of those.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
Now that we have two kinds of grabs, the intricacies of event delivery
got slightly more complicated. So this seems like a good point to
introduce a new GRABS debug flag that gives an overview of which grabs
are currently in effect.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
