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>
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>
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>
This partly reverts f9857cb8 but leaves an exception for cursor
surfaces in place, as some apps/toolkits will likely not get updated
anytime soon to ensure cursor themes comply with the Wayland spec.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2815>
We may fall through these paths on --nested too, resulting in us poking the
wrong internals from the wrong MetaRenderer subclass. Fixes launching of
clients using wl_drm in --nested.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2818>
This is a public API change. Add device/sequence parameters to this
operation, so that window dragging and resizing can stick to one
set of pointing events of them all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Flip the switch in using MetaWindowDrag, leaving display grab
ops and a bunch other code unused. Some places checked the grab op
and/or window in complex ways, others just checked for grab existence
and should now look for clutter ones, and others already were already
doing this in addition.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
The final effect of this boolean can now be expressed through the
META_GRAB_OP_WINDOW_FLAG_UNCONSTRAINED flag to MetaGrabOp. Use that
in the relevant places, and drop the argument.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This is no longer necessary to prevent the bits we wanted to be
prevented by the presence of this grab. We can drop this, and
let it work through the MetaWaylandPointerGrab interface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
The GQueue node for transactions are inlined in the transaction struct,
meaning we should never let the GQueue API free the node itself, as that
actuall frees the transaction itself.
We did this during tear down if there were left-over transactions,
meaning we ended up with use-after-free issues after having popped
transactions from the queue.
Fix this by just popping the link itself, which won't attempt to free
it. It is effectively freed when freeing the transaction itself so we
won't leak any memory.
Fixes: 56260e3e07
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2805>
That means before-update, prepare-paint, before-paint, paint-view, after-paint,
after-update. While yet to be used, it will be used as a transient frame
book keeping object, to maintain object and state that is only valid
during a frame dispatch.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2795>
This define was dropped by commit 0e8aaebc00 (xwayland: Make
XSetIOErrorExitHandler() mandatory), but some #ifdef checks were
brought back by commit 36f30341ac (wayland: Add a prepare-shutdown
signal).
Since there's no define anymore in config.h, these pieces of code
were unintentionally disabled, and a meta_get_display() call be
also left over. Remove the ifdefs and update the code to build
again.
Fixes: 36f30341ac - wayland: Add a prepare-shutdown signal
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2786>
Quoting Carlos:
The META_PRIORITY_EVENTS ± 1 happening below are in order to set these idles
and timeouts in a priority that is relative to the literal GDK event priority,
making those diverge is a likely way to sneakily break things.
But that's unlikely to happen, and decoupling mutter from GTK further
should make it moot, so perhaps it's alright after all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2407>
This replaces the v1 implementation, which is now renamed to
legacy-xdg-foreign. Both implementations use the same data structures
internally, so that protocol version mismatches between
the importer client and exporter client don't fail.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2770>
Things like meta_compositor_destroy() and meta_compositor_add_window()
isn't intended to be used externally, and if they was, things would
probably fall apart rather quickly.
MetaCompositor also isn't introspected, meaning things that technically
belong to the compositing parts isn't easily available via some object,
but much take detours via other objects like MetaDisplay.
So move the API intended for internal usage to compositor-private.h, and
leave API that is meant to be expose in the public compositor.h.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
As with the backend commit, this means all objects can reach the
MetaContext by walking up the chain, thus can e.g. get the backend from
the context, instead of the global singleton.
This also is a squashed commit containing:
compositor: Get backend via the context
The MetaCompositor instance is owned by MetaDisplay, which is owned by
MetaContext. Get the backend via that chain of ownership.
dnd: Don't get backend from singleton
window-actor: Don't get backend from singleton
dnd: Don't get Wayland compositor via singleton
background: Don't get the monitor manager from the singleton
plugins: Don't get backend from singleton
This applies to MetaPlugin, it's manager class, and the default plugin.
feedback-actor: Pass a compositor pointer when constructing
This allows getting to the display.
later: Keep a pointer to the manager object
This allows using the non-singleton API in idle callbacks.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
As elsewhere, make sure objects that need to have a ownership up to the
context, and use this ownership chain to find relevant components, such
as the backend or the Wayland compositor object instance.
wayland/data-device: Hook up data devices to seats
They are tied to a seat - make that connection in struct fields too, so
that related objects can get to the context via it.
wayland: Don't get Wayland compositor via singleton getter
This means via the ownership chain or equivalent.
xwayland: Hook up manager to Wayland compositor
Same applies to the drag-n-drop struct.
xwayland: Make X11 event handling compositor instance aware
This avoids finding it via singletons in the callee.
xwayland: Don't get Wayland compositor from singleton
xwayland: Pass manager when handling dnd event
window/xwayland: Don't get Wayland compositor from singleton
xwayland/grab-keyboard: Don't get backend from singleton
xwayland: Don't get backend from singleton
wayland: Always get the backend from the context
This means traveling up the ownership chain or equivalent when
necessary.
wayland: Hook up data devices, offers and sources to the compositor
This allows tying them to a context without going through any
singletons.
wayland: Don't get display from singleton
xwayland: Don't get display from singleton
tablet: Don't get display from singleton
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
As with other parts, make objects have the ability to walk up the
ownership chain to the context, to get things like the Wayland
compositor or backend instances.
Contains these squashed commits:
display: Don't get backend from singleton
window: Don't get backend from singleton
keybindings: Don't get backend from singleton
workspace: Don't get backend from singleton
display: Don't get Wayland compositor from singleton
selection: Add display getter
context/main: Get backend directly from the context
clipboard-manager: Don't get display from singleton
stack-tracker: Don't use singleton MetaLater API
startup-notification: Hook up sequences and activations to display
This allows using context aware API directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
This code path is important for "empty" commits to ensure we schedule
frame callbacks even if previous commits didn't cause stage redraws.
There is, however, no reason to schedule updates on all stage views
instead of only those the actor is on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
Avoid some allocations, save some CPU cycles and make the code easier
to read.
Behaviourwise the only expected change is that now, if there are mapped
clones, we unconditionally choose the view with the highest refresh
rate the actor (or one of its clones) is on and don't check the
obscurred region any more.
Thus in some cases a client may receive a higher rate of frame callbacks
when obscured on a faster view while a clone is present on a slower
one. The assumption is that cases like this are relatively rare and
that the reduction of code complexity, the reduction of allocations in
`meta_surface_actor_is_obscured_on_stage_view()` whenever the actor is
not fully obscured and has clones on other views, as well as generally
fewer lookups and less code in most common cases, compensate for that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
After the commit "wayland/subsurface: Implement
meta_wayland_surface_get_window()" subsurfaces are supported. Adjust
some comments and fix a warning that could occur when closing a window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2717>
The intention here was to check if the subsurface belongs to a window.
Thus it didn't behave as expected for subsurfaces belonging to non-toplevel
windows.
After the previous commit we can use `get_window()` to check for what we
actually want here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2717>
Subsurfaces are special regarding windows as they don't have a window,
but usually have an ancestor which does. All current users of
`get_window()` are either used for known surface roles, such as xdg-*
ones, or, as is the case for pointer constrains, would actually want to
get the ancestors window.
Thus implement `get_window()` to allow pointer constrains to work.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2223
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2717>
