Preparation for potentially calling meta_wayland_transaction_apply some
time after surface commit, in which case doing it in the former would be
too late: The client may legally destroy the attached wl_buffer
immediately after commit, in which case meta_wayland_buffer_attach would
spuriously fail and disconnect the client (or possibly even crash mutter
due to NULL error).
Requires splitting up the surface texture between protocol and output
state, and propagating from the former to the latter via
MetaWaylandSurfaceState.
v2: (Jonas Ådahl)
* Move meta_wayland_surface_get_texture call to separate line.
* Use g_autoptr for GError.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
And keep track of the hierarchy separately for the Wayland protocol and
for output. Protocol state is updated immediately as protocol requests
are processed, output state only when the corresponding transaction is
applied (which may be deferred until the next commit of the parent
surface).
v2:
* Directly add placement ops to a transaction, instead of going via
pending_state.
* Use transaction entry for the sub-surface instead of that for its
parent surface.
v3:
* Use transaction entry for the parent surface again, to ensure proper
ordering of placement ops, and call
meta_wayland_surface_notify_subsurface_state_changed only once per
parent surface.
* Drop all use of wl_resource_add_destroy_listener, transactions are
keeping surfaces alive as long as needed.
v4:
* Rebase on https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2501
* Drop ClutterActor code from meta_wayland_surface_apply_placement_ops.
(Robert Mader)
v5:
* Rename MetaWaylandSubSurfaceState to MetaWaylandSurfaceSubState, since
the next commit adds not sub-surface specific state to it.
v6:
* Move include of meta-wayland-subsurface.h from
meta-wayland-transaction.c to .h, since the latter references
MetaWaylandSubsurfacePlacementOp.
v7:
* Drop superfluous !entry check from meta_wayland_transaction_apply.
v8:
* Rename output/protocol fields to output/protocol_state. (Jonas Ådahl)
v9:
* Use meta_wayland_surface_state_new in
meta_wayland_transaction_add_placement_op.
v10:
* Fix a few style issues per check-style.py.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Destroy Wayland protocol related state immediately when the Wayland
resource is destroyed, but keep the rest alive by any transaction which
references the surface.
This makes it easier and cleaner to deal with a surface getting
destroyed while it's still referenced by transactions.
v2:
* No more need to keep references for surfaces in the entries hash
table.
v3:
* Do not use surface->sub.transaction in wl_surface_destructor, just
destroy it.
v4:
* No need for wl_surface_destructor to use its own transaction.
v5:
* Use g_steal_pointer & (more) g_clear_pointer in wl_surface_destructor.
v6:
* Leave SURFACE_DESTROY signal emission in wl_surface_destructor.
v7:
* Use finalize instead of dispose callback.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
This keeps all surfaces referenced by a transaction alive until the
transaction is destroyed, and makes sure transactions are applied in
the same order as they were committed with respect to all surfaces
they reference.
v2:
* Guard against NULL entry in meta_wayland_transaction_apply.
v3:
* Keep single entries hash table.
v4:
* Unref the surface in the meta_wayland_transaction_merge_into while
loop only if the "to" transaction didn't already have an entry for it,
to prevent premature finalization of the surface (likely followed by a
crash).
v5:
* Unref the surface (implicitly via g_hash_table_iter_remove) in the
meta_wayland_transaction_merge_into while loop even if the "to"
transaction already had an entry for it, or we leak a reference.
* Use g_clear_object & g_steal_pointer to not leave behind a dangling
from->state pointer in meta_wayland_transaction_entry_merge_into.
v6:
* Add curly braces around
meta_wayland_transaction_add_placement_surfaces calls. (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Instead of cached_state.
surface_commit for a synchronized sub-surface either commits the
transaction or merges it into the parent surface's transaction (if
the parent is a synchronized sub-surface itself).
This should fix or at least improve the behaviour of nested synchronized
sub-surfaces.
Also change wl_subsurface_set_desync:
* Commit sub-surface transactions separately. This may allow some of
them to be applied earlier in some cases.
* Commit transaction only for descendant sub-surfaces which become
newly de-synchronized themselves.
v2:
* Drop unused function prototypes
v3:
* Use g_clear_pointer for surface->sub.transaction.
v4:
* Use g_steal_pointer instead of g_clear_pointer. (Sebastian Wick, Jonas
Ådahl)
v5: (Carlos Garnacho)
* Add spaces between type casts and values.
* Use (gpointer *) instead of (void**).
v6: (Jonas Ådahl)
* Use g_clear_object in meta_wayland_transaction_entry_merge_into.
* Use meta_wayland_transaction_entry_free in
meta_wayland_transaction_merge_into.
* Fix alignment of meta_wayland_transaction_merge_pending_state
parameters.
* Remove unused meta_wayland_transaction_add_state declaration.
v7:
* Use meta_wayland_surface_state_new in
meta_wayland_transaction_merge_pending_state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
A transaction contains the committed state for a surface, plus any
cached state for synchronized subsurfaces.
v2:
* Handle sub-surface positions separately from surface states.
v3:
* Sync child states only for surfaces with state in the transaction.
v4: (Jonas Ådahl)
* Drop unnecessary g_object_new call from wl_subsurface_set_desync. (me)
* Fix indentation & formatting in meta_wayland_surface_commit.
* Add meta_wayland_surface_state_new helper function.
* Fix alignment of meta_wayland_transaction_apply_subsurface_position
parameters.
* Add curly braces around meta_wayland_transaction_sync_child_states
call in meta_wayland_transaction_apply.
v5:
* Make meta_wayland_surface_state_new an inline function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
If multiple transactions have entries for the same surface, they are
applied in the same order as they were committed. Otherwise, they can
be applied in any order.
This is preparation for following changes, transactions are still
applied as soon as they're committed.
v2:
* Move GQueue for transactions to MetaWaylandCompositor (Jonas Ådahl)
v3
* Say "entry for" instead of "state for", since there can be transaction
entries with no state (for surfaces which are getting destroyed).
v4:
* Use a hash table to keep track of all candidate transactions which
might be newly ready to be applied.
* Use clearer function / variable names.
v5:
* Use custom single-linked list instead of hash table for candidate
transactions, ordered by the transaction commit sequence number, so
that they're attempted to be applied in the same order as they were
committed.
* Rename transaction->queue to transaction->committed_queue, and
simplify its handling.
v6: (Carlos Garnacho)
* Add spaces between type casts and values.
* Use (gpointer *) instead of (void**).
v7: (Jonas Ådahl)
* Use G_MAXSIZE instead of ULONG_MAX.
* Fix indentation of meta_wayland_transaction_apply &
meta_wayland_transaction_maybe_apply_one parameters.
* Refactor find_next_transaction_for_surface & ensure_next_candidate
helper functions out of meta_wayland_transaction_apply.
* Refactor has_unapplied_dependencies helper function out of
meta_wayland_transaction_maybe_apply_one.
* Make while (TRUE) loop in meta_wayland_transaction_maybe_apply
consistent with general usage.
* Drop unused value local from meta_wayland_transaction_commit.
* Store pointer to compositor object in transactions, instead of
pointer to the queue of committed transactions.
* Drop tautological g_assert from meta_wayland_transaction_apply. (me)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
v2:
* Use single hash table with struct which will contain all kinds of
state handled by a transaction.
v3:
* Add meta_wayland_transaction_destroy.
v4 (Georges Basile Stavracas Neto)
* Fix struct _MetaWaylandTransaction(Entry) formatting.
* Explicitly test against NULL.
* Use gpointer insteadof void * for
meta_wayland_transaction_entry_destroy.
v5: (Robert Mader)
* Use for loop in is_ancestor.
* Include meta-wayland-transaction.h first in
meta-wayland-transaction.c.
v6:
* Use g_autofree & g_clear_object.
v7: (Jonas Ådahl)
* Rename meta_wayland_transaction_entry_destroy to
meta_wayland_transaction_entry_free.
* Drop g_autofree use from meta_wayland_transaction_entry_free again.
* Make meta_wayland_transaction_entry_free take a
MetaWaylandTransactionEntry pointer.
* Rename meta_wayland_transaction_destroy to
meta_wayland_transaction_free.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Need to deal with surface->resource == NULL and
surface->pending_state == NULL in some places.
v2:
* Avoid expanding conditions to multiple lines.
(Georges Basile Stavracas Neto)
v3:
* Use a single bailout condition in meta_wayland_client_owns_window as
well.
v4:
* Remove spare empty line in meta_wayland_surface_apply_state.
(Robert Mader)
* Add wl_resource_post_error calls in xdg-shell request handlers.
(Robert Mader)
* Drop checks in functions which can only be called if there's a valid
resource.
* Drop more checks which are unnecessary due to leaving the
SURFACE_DESTROY signal emission in wl_surface_destructor later.
v5:
* Move resource = surface->resource assignments to if (!resource) tests.
(Jonas Ådahl)
v6:
* Fix style issue per check-style.py.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Creates a GSource which will call the specified dispatch callback when
all dma-buf file descriptors for the buffer have become readable.
v2:
* Hold a reference to the buffer in the source, to prevent the buffer
from getting destroyed before the source.
v3:
* Do not use check callback, handle everything in dispatch callback.
(Dor Askayo)
v4: (Georges Basile Stavracas Neto)
* Define and use MetaWaylandDmaBufSource & MetaWaylandDmaBufSourceDispatch
types.
* Fix meta_wayland_dma_buf_source_dispatch &
meta_wayland_dma_buf_source_funcs formatting.
* Use gpointer instead of void*.
* Rename meta_wayland_dma_buf_get_source to
meta_wayland_dma_buf_create_source. (Carlos Garnacho)
v5:
* Explicitly handle NULL return value. (Jonas Ådahl)
v6:
* Fix style issue per check-style.py.
v7:
* Fix code style harder. (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
And call it from meta_wayland_buffer_realize. This makes dma-buf fds
available for EGL image type buffers as well.
v2:
* Move buffer->dma_buf.dma_buf assignment value to next line.
(Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Currently, we will notify the display about a new window being created
during the constructed phase of the GObject. During this time,
property-change notifications are frozen by GObject, so we'll emit a few
::notify signals only after the window-created signal, although
the actual property change happened before that.
This caused confusion in gnome-shell code where a notify::skip-taskbar =
true emission was seen when the property already was true inside a
window-created handler before.
In order to fix that that, we notify the window creation
post-construction
of the GObject on GInitable.init vfunc
Details
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6119#note_1598983
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6119
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2703>
A client may provide a positioner that places the window outside of its
parent. This isn't allowed, according to spec, so we hide the window and
log a warning. This, however, leads these affected clients with an
incorrect view of what is mapped or not, meaning it becomes harder to
recover.
Fix this by sending xdg_popup.done when we hide the popup due to an
invalid position. Don't error out the client, let the bug slide, as
that's a less jarring experience for existing applications that
reproduce this than being disconnected, which practically feels like a
crash.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2408
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2645>
This reverts commit eac227a203.
Currently, Flatpak applications can bypass the X11 permission setting
and access the X server through abstract sockets because X11 authentication
is not enforced for the current user ID.
Fix this by always requiring X11 authentication for Xwayland. This also
means applications without XAUTHORITY set to the file with Mutter's
Xwayland credentials cannot connect to X, including apps launched from
VT or SSH.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2633>
Back in 2014 sending pressed keys to Wayland clients caused issues,
because at least Xwayland didn't handle that gracefully, causing issues
like ghost-pressed keys. A way it was reproduced was quickly alt-tab:ing
to and from a Firefox window, which would cause the File menu bar
incorrectly appearing.
While this was reported to the Xwayland component back then, it was,
probably by mistake, assumed to be an issue in mutter, and mutter
stopped sending pressed key events on enter.
The following year, Xwayland was eventually fixed, but the work around
in mutter has been kept around until it was again noticed as an
inconsistency between compositor implementations.
Lets remove the work around, and follow the spec, again.
This reverts commit c39f18c2d4.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2457
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2657>
We'd set the capabilities to 'none', meaning all previously enabled
device classes would be disabled. That means we shouldn't re-disable
them directly after.
This ensures '..disable()' is only called once for every '..enable()'.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2657>
In fcfe90aa, multiple for loops were replaced with
META_WAYLAND_SURFACE_FOREACH_SUBSURFACE.
However, this substitution was not side-effect free, and introduced a
null-pointer dereference risk as shown in the example below:
Old:
for (n = g_node_first_child (surface->subsurface_branch_node);
n;
n = g_node_next_sibling (n))
{
if (G_NODE_IS_LEAF (n))
continue;
meta_wayland_surface_update_outputs_recursively (n->data);
}
n is checked for NULL during each loop in the condition expression.
Therefore, when `G_NODE_IS_LEAF (n)` is called, `n` is guaranteed not to
be NULL. Note also that g_node_first_child is also NULL-safe since it
performs a NULL check internally.
New:
META_WAYLAND_SURFACE_FOREACH_SUBSURFACE (surface, subsurface_surface)
meta_wayland_surface_update_outputs_recursively (subsurface_surface);
=
for (GNode *G_PASTE(__n, __LINE__) = meta_get_first_subsurface_node ((surface)); \
(subsurface = (G_PASTE (__n, __LINE__) ? G_PASTE (__n, __LINE__)->data : NULL)); \
G_PASTE (__n, __LINE__) = meta_get_next_subsurface_sibling (G_PASTE (__n, __LINE__)))
In the new logic `subsurface` is still checked for NULL in the loop
condition. However, in the new loop init:
...
meta_get_first_subsurface_node (MetaWaylandSurface *surface)
...
n = g_node_first_child (surface->subsurface_branch_node);
if (!G_NODE_IS_LEAF (n))
...
The above implementation performs a `G_NODE_IS_LEAF` call, which
performs a dereference on `n`, without first checking for NULLs.
This NULL dereference triggers the following gnome-shell crash:
Core was generated by `/usr/bin/gnome-shell'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 meta_get_first_subsurface_node (surface=0x55d589623450) at ../src/wayland/meta-wayland-surface.h:399
#1 pointer_can_grab_surface (pointer=0x7f6dc4012700, surface=0x55d589623450) at ../src/wayland/meta-wayland-pointer.c:1306
#2 0x00007f6ddb94d509 in meta_wayland_pointer_can_grab_surface (pointer=<optimized out>, surface=surface@entry=0x55d589623450, serial=serial@entry=996) at ../src/wayland/meta-wayland-pointer.c:1321
#3 0x00007f6ddb950d05 in meta_wayland_seat_get_grab_info (seat=seat@entry=0x55d586c24f20, surface=0x55d589623450, serial=996, require_pressed=require_pressed@entry=0, x=x@entry=0x0, y=y@entry=0x0)
at ../src/wayland/meta-wayland-seat.c:467
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2655>
Fullscreen Wayland toplevel surfaces don't need to respect the
configured size in which case it should be shown centered on the monitor
with a black background. The black background becomes part of the window
geometry.
The surface container is responsible for correctly culling the surfaces
and making sure the surface actors are removed from the actor tree to
avoid destroying them.
The window actor culling implementation assumes all surfaces to be direct
children of said actor. The introduction of the surface_container actor
broke that assumption. This implements the culling interface in
MetaWindowActorWayland which is aware of the actor surface_container and
fullscreen state.
v2: Fix forwarding culling to surface even if there is a background.
v2: Don't alter passed geometry.
v2: Update window geometry code documentation to reflect these changes.
v2: Only use constrained rect if we're acked fullscreen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
This is helpful to know what current state a window actually have, in
contrast to the state in MetaWindow (e.g. MetaWindow::fullscreen) which
is the intended state, be it current or not yet so.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
First make sure we call 'move_resize()' in all cases where the size or
position can change, then move the updating of the buffer rect to the
same place as we update the frame rect. This means keeping track of
surface size changes, in addition to geometry changes, and calling
finish_move_resize() whenever any of those changes, in addition to
acknowledged configurations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
When a window configuration is constructed for a Wayland surface it
contains a position, size and a scale. The scale is the geometry scale
for the configuration, i.e. before the size is sent the passed dimension
is divided with the passed scale.
When moving between monitors with different scales, if we use the
existing geometry scale, this means we will send a configure event with
incorrect dimensions. Fix this by calculating the scale used in the
configuration given the rect we're configuring with as this will mean
the correct size will be sent to the client.
v2: Removed the fullscreen condition. Don't know why it was added to
begin with.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
There were some magic conditions that decided when
meta_window_constrain() was to be called or not. Reasoning about and
changing these conditions were complicated, and in practice the caller
knows when constraining should be done. Lets change things by adding a
'constrain' flag to the move-resize flags that makes this clearer. This
way we can, if needed, have better control of when a window is
constrained or not without leaking that logic into the generic
to-constrain-or-not expression.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
We'll never scan out, which is why ADDFB2 is required otherwise, and we
won't enable the DMA buffer extension if
'EGL_EXT_image_dma_buf_import_modifiers' is missing, so send modifiers
in this case.
This also happens to avoid crashing when the GPU is null, since we'd
otherwise attempt to dereference it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2578>
This is what the protocol says we should do, and even though normally
an out of focus client should not have any reason to create IM requests,
there is a bit of a grey area around focus changes, as both the client
losing focus and the client gaining focus may respectively try to
disable/enable in an undetermined order.
Anyways, since in that situation the client losing focus is not aware
of the requests being ignored, the serial should always be incremented
in order not to break accounting of .done/.commit for that specific
client.
Fixes the IM focus being possibly "lost" after changing focus between
clients, if the race condition turned the odds in that direction.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2585>
Same applies to MetaOutput. The reason for this is to make it possible
to more reliably know when there was EDID telling us about these
details. This will be used for colord integration.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
In the timespan between an activation token being created and the
token being used by the activated application, the surface that started
the activation request may end up destroyed/disposed.
In that case, the token would be left with a stale surface pointer,
maybe causing crashes later on. Set up a destroy notification listener
so that we do know to unset the token surface if that situation arises,
this will result in Mutter not considering the token activatable, thus
maybe issuing the "Application needs attention" notification if the
activated surface did not immediately get focus. In any case this is
better than a compositor crash.
A typical situation where this may happen is "Open With..." dialogs,
since those don't live long after launching the application.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2390
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2592>
There is some surface tracking going on here, and all notify handlers
are possibly leaving the linked wl_listener behind. Ensure it is unlinked
in all destroy notification functions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2588>
This condition is inverted of how it should be. Since pad focus relies
on grouped devices lookups (e.g. pads not grouped with a tablet do not
focus surfaces), this fixes issues in pad focus and event propagation to
wayland clients.
Fixes: fff3654941 - wayland: Check input device capabilities in tablet seats
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2573>
If the window didn't have a size, it would still have a monitor, and
when we are asked to update, we must update, as the old monitor might
not be kept around, leaving us vulnerable to use after free.
Avoid not updating the monitor by using the stored IDs (preferred, or
previous) to find suitable logical monitors, with the primary monitor
being the last fallback unless we're completely headless.
This fixes the assert
!window->monitor ||
g_list_find (meta_monitor_manager_get_logical_monitors (monitor_manager),
window->monitor)
in meta_window_update_for_monitors_changed() being hit when a Wayland
window has been created, but not mapped, when a hotplug happens.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
The function finds a suitable logical monitor given the window
rectangle; this wasn't all that clear from the name
"calculate_main_logical_monitor".
This is in preparation for finding a new logical monitor using things
other than the geometry of the window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
Now that we support Wayland buffer transforms in all cases, we can
properly report them to outputs.
Also make sure we resend the output geomerty on transform changes.
This partly reverts commit bda9c359
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/344>
The "single pixel buffer" Wayland protocol extension provides a way for
clients to create 1x1 buffers with a single color, specified by
providing the color channels (red, green and blue) as well as the
alpha channel as a 32 bit unsigned integer.
For now, this is turned into a 1x1 texture. Future potential
improvements is to hook things up to the scanout candidate logic and
turn it into a scanout capable DMA buffer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2246>
To Wayland clients, it doesn't matter how we configure our onscreen
buffers, since they don't necessarily have the same bandwidth issues
related to mode setting, whichis the primary reason why we disable
modifiers using the udev rule, so simply check whether importing with
modifiers will work at all and advertise modifiers if so is the case.
This might help avoid issues using legacy non-modifiers path in drivers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2546>
As testing of direct scanout revealed, `META_MONITOR_TRANSFORM`
does actually match `WL_OUTPUT_TRANSFORM` enums. The fact that
things rendered correctly with 90/270 degree values swapped
was because other parts of the stack got the interpretation
wrong, most notably `meta_rectangle_transform()`.
Thus lets revert this change and fix the stack accordingly.
This reverts commit 8d9bbe109b.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2459>
Fixes memory leak:
==995170== 936 (40 direct, 896 indirect) bytes in 1 blocks are definitely lost in loss record 15,090 of 15,641
==995170== at 0x48445EF: calloc (vg_replace_malloc.c:1328)
==995170== by 0x4B211D0: g_malloc0 (gmem.c:155)
==995170== by 0x4A56693: meta_wayland_tablet_manager_new (meta-wayland-tablet-manager.c:109)
==995170== by 0x4A56693: meta_wayland_tablet_manager_init (meta-wayland-tablet-manager.c:126)
==995170== by 0x4A3FA95: meta_wayland_compositor_new (meta-wayland.c:626)
==995170== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==995170== by 0x10F065: main (mutter.c:148)
Fixes: 745cb67988 ("wayland: Initialize the MetaWaylandTabletManager")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
Fixes memory leak:
==995170== 383 (96 direct, 287 indirect) bytes in 1 blocks are definitely lost in loss record 14,733 of 15,641
==995170== at 0x483F7B5: malloc (vg_replace_malloc.c:381)
==995170== by 0x4B21178: g_malloc (gmem.c:125)
==995170== by 0x4B395C0: g_slice_alloc (gslice.c:1072)
==995170== by 0x4B0766D: g_hash_table_new_full (ghash.c:1071)
==995170== by 0x4A4A8B4: meta_wayland_compositor_update_outputs (meta-wayland-outputs.c:483)
==995170== by 0x4A4ABAB: meta_wayland_outputs_init (meta-wayland-outputs.c:716)
==995170== by 0x4A3FA65: meta_wayland_compositor_new (meta-wayland.c:620)
==995170== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==995170== by 0x10F065: main (mutter.c:148)
v2:
* Use meta_backend_get_monitor_manager. (Jonas Ådahl)
Fixes: 9a4783e364 ("Integrate the monitor manager with wayland")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
Fixes memory leak:
==995170== 288 (96 direct, 192 indirect) bytes in 1 blocks are definitely lost in loss record 14,607 of 15,641
==995170== at 0x483F7B5: malloc (vg_replace_malloc.c:381)
==995170== by 0x4B21178: g_malloc (gmem.c:125)
==995170== by 0x4B395C0: g_slice_alloc (gslice.c:1072)
==995170== by 0x4B0766D: g_hash_table_new_full (ghash.c:1071)
==995170== by 0x4A4F973: meta_wayland_init_presentation_time (meta-wayland-presentation-time.c:222)
==995170== by 0x4A3FB04: meta_wayland_compositor_new (meta-wayland.c:635)
==995170== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==995170== by 0x10F065: main (mutter.c:148)
Fixes: dccc60ec3e ("wayland: Implement stub presentation-time")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
Fixes memory leak:
==995170== 240 (48 direct, 192 indirect) bytes in 1 blocks are definitely lost in loss record 14,428 of 15,641
==995170== at 0x48445EF: calloc (vg_replace_malloc.c:1328)
==995170== by 0x4B211D0: g_malloc0 (gmem.c:155)
==995170== by 0x4A3CDB3: meta_wayland_activation_init (meta-wayland-activation.c:383)
==995170== by 0x4A3FB0C: meta_wayland_compositor_new (meta-wayland.c:636)
==995170== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==995170== by 0x10F065: main (mutter.c:148)
Fixes: ec390b68c5 ("wayland: Implement the xdg-activation protocol")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
Fixes memory leak:
==995170== 192 (96 direct, 96 indirect) bytes in 1 blocks are definitely lost in loss record 14,260 of 15,641
==995170== at 0x483F7B5: malloc (vg_replace_malloc.c:381)
==995170== by 0x4B21178: g_malloc (gmem.c:125)
==995170== by 0x4B395C0: g_slice_alloc (gslice.c:1072)
==995170== by 0x4B0766D: g_hash_table_new_full (ghash.c:1071)
==995170== by 0x4A3F3A4: meta_wayland_compositor_init (meta-wayland.c:477)
==995170== by 0x4E1F509: g_type_create_instance (gtype.c:1929)
==995170== by 0x4E03DFC: g_object_new_internal (gobject.c:2011)
==995170== by 0x4E0538C: g_object_new_with_properties (gobject.c:2181)
==995170== by 0x4E05D40: g_object_new (gobject.c:1821)
==995170== by 0x4A3F8C4: meta_wayland_compositor_new (meta-wayland.c:590)
==995170== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==995170== by 0x10F065: main (mutter.c:148)
Fixes: 8df2a1452c ("wayland: Notify actively of xwayland window/surface associations")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
Fixes potential use-after-free during mutter shutdown, e.g.:
==993876== Invalid read of size 8
==993876== at 0x4A4FCA3: meta_wayland_presentation_time_ensure_feedbacks (meta-wayland-presentation-time.c:373)
==993876== by 0x4A3F07F: on_presented (meta-wayland.c:282)
==993876== by 0x661B7E9: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==993876== by 0x661A922: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==993876== by 0x4DFF4BC: g_cclosure_marshal_generic_va (gclosure.c:1648)
==993876== by 0x4DFE948: _g_closure_invoke_va (gclosure.c:893)
==993876== by 0x4E17498: g_signal_emit_valist (gsignal.c:3406)
==993876== by 0x4E176BE: g_signal_emit (gsignal.c:3553)
==993876== by 0x51D9DB5: clutter_stage_view_notify_presented (clutter-stage-view.c:1226)
==993876== by 0x499ACD2: frame_cb (meta-stage-view.c:83)
==993876== by 0x499ACD2: frame_cb (meta-stage-view.c:43)
==993876== by 0x50CAA41: notify_event (cogl-onscreen.c:175)
==993876== by 0x50CAA41: _cogl_onscreen_notify_complete (cogl-onscreen.c:545)
==993876== by 0x4A877F5: meta_onscreen_native_notify_frame_complete (meta-onscreen-native.c:211)
==993876== Address 0x24b7be58 is 296 bytes inside a block of size 344 free'd
==993876== at 0x484217B: free (vg_replace_malloc.c:872)
==993876== by 0x4E1F88B: g_type_free_instance (gtype.c:2001)
==993876== by 0x49C793C: meta_context_dispose (meta-context.c:675)
==993876== by 0x4E037E0: g_object_unref (gobject.c:3636)
==993876== by 0x4E037E0: g_object_unref (gobject.c:3553)
==993876== by 0x10F145: glib_autoptr_clear_GObject (gobject-autocleanups.h:27)
==993876== by 0x10F145: glib_autoptr_clear_MetaContext (meta-context.h:32)
==993876== by 0x10F145: glib_autoptr_cleanup_MetaContext (meta-context.h:32)
==993876== by 0x10F145: main (mutter.c:126)
==993876== Block was alloc'd at
==993876== at 0x483F7B5: malloc (vg_replace_malloc.c:381)
==993876== by 0x4B21178: g_malloc (gmem.c:125)
==993876== by 0x4B395C0: g_slice_alloc (gslice.c:1072)
==993876== by 0x4B39C29: g_slice_alloc0 (gslice.c:1098)
==993876== by 0x4E1F544: g_type_create_instance (gtype.c:1901)
==993876== by 0x4E03DFC: g_object_new_internal (gobject.c:2011)
==993876== by 0x4E0538C: g_object_new_with_properties (gobject.c:2181)
==993876== by 0x4E05D40: g_object_new (gobject.c:1821)
==993876== by 0x4A3F864: meta_wayland_compositor_new (meta-wayland.c:585)
==993876== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==993876== by 0x10F065: main (mutter.c:148)
Fixes: 2ce3a050f0 ("wayland: Wire up presentation-time machinery")
Fixes: 8cff3b84f7 ("wayland/compositor: Process frame callbacks on 'after-update'")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
When building the list of formats to be sent as part of the scanout
tranche, avoid requiring modifier support by the DRM driver for
formats relying on implicit modifiers (DRM_FORMAT_MOD_INVALID).
Specifically, the previous check required the DRM driver to have
advertised some modifier support for the given format in its
IN_FORMATS KMS plane property, regardless of modifier it was. If it
hadn't, the format was left out of the list of formats to be sent
in the scanout tranche.
When no formats remained to be sent in the scanout tranche, the
tranche simply wasn't sent.
This resulted in the scanout tranche never being sent for GPUs where
modifiers aren't supported. In those cases, no formats are advertised
using the IN_FORMATS property, and thus the list of formats to be sent
in the scanout tranche remained empty.
Since Mesa doesn't use scanout-compatible buffers for native Wayland
clients unless specifically requested to do so using the "scanout"
tranche flag, it effectively means that direct scanout of native
Wayland clients wasn't supported for GPUs without modifiers support.
Sending a tranche with formats paired with the implicit modifier
(DRM_FORMAT_MOD_INVALID) is both allowed by the protocol and is
already done by default for GPUs with modifiers support, unless the
experimental support for explicit modifiers is enabled in Mutter.
So instead of requiring modifiers to be supported for each format
being evaluated for the scanout tranche, when processing formats
which rely on implicit modifiers, only check if the format in
question is supported by the DRM driver for scanout on the primary
plane.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2510>
While the check for `clutter_actor_has_mapped_clones` clearly indicates
an intention to take clones into account, the following code
does not do so, likely because it predates the introduction of
`clutter_actor_is_effectively_on_stage_view()`.
Switch to that newer API in order to take clones into account. This
avoids unnecessary `wl_surface_send_enter()` and `wl_surface_send_leave()`
events when entering the overview, reducing client work.
This also avoids unnecessarily allocating a `cairo_region_t`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2502>
Unparenting the surface actor when the subsurface object is destroyed
has several issues:
- subsurface actors can be unparented while a close animation is
still ongoing, breaking the animation for e.g. Firefox.
- adding and removing the actor to/from the parent is not handled in
one place, making the code harder to follow.
- if the destroyed subsurface had children of its own, they potentially
stick around until a surface-tree rebuild. This makes the Firefox
hamburger menu not close with the "compositor" backend.
Move the unparenting back to
`meta_window_actor_wayland_rebuild_surface_tree()` and instead just
notify the parent of a state change, if it still exist. This will ensure
a correct mapping between the subsurface node tree and the flat surface
actor list. In case of the closing animation the parent will already be
removed and the call is skipped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2501>
Fixes leak:
==14889== 2,168 (16 direct, 2,152 indirect) bytes in 1 blocks are definitely lost in loss record 15,308 of 15,584
==14889== at 0x48445EF: calloc (vg_replace_malloc.c:1328)
==14889== by 0x4BAC1D0: g_malloc0 (gmem.c:155)
==14889== by 0x4AAFF60: meta_wayland_dma_buf_feedback_new (meta-wayland-dma-buf.c:298)
==14889== by 0x4AAFFE0: meta_wayland_dma_buf_feedback_copy (meta-wayland-dma-buf.c:317)
==14889== by 0x4AB16B6: ensure_surface_feedback (meta-wayland-dma-buf.c:1121)
==14889== by 0x4AB1848: dma_buf_handle_get_surface_feedback (meta-wayland-dma-buf.c:1169)
==14889== by 0x66F77E9: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==14889== by 0x66F6922: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==14889== by 0x5318750: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-server.so.0.20.0)
==14889== by 0x5313B99: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-server.so.0.20.0)
==14889== by 0x5316649: wl_event_loop_dispatch (in /usr/lib/x86_64-linux-gnu/libwayland-server.so.0.20.0)
==14889== by 0x4AA7C19: wayland_event_source_dispatch (meta-wayland.c:110)
Fixes: 64e6bedb6b ("wayland/dma-buf: Add support for scanout surface feedback")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2469>
The min distance to the right/bottom edge depends on Wayland concepts
(wl_fixed_t) and eventually geometry scale. Move the logic the Wayland
side of the pointer constraints machinery to avoid the backend trying to
figure this out without the proper data.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2460>
Add `sync_effects_completed()` and `verify_view()` in
order to allow Wayland test clients to trigger verifications
and add convenience functions to use them to client-utils.
Notes:
- `sync_effects_completed()` works in two stages in order
to ensure it doesn't race with window effects. By the time
`sync_effects_completed()` is processed, an effect could
already have ended or not yet been scheduled. Thus we
defer a check for pending effects to the next paint cycle,
assuming that by then they should have been scheduled.
- `meta_ref_test_verify_view()` internally triggers the
`paint` signal for the stage which is why it can not be run
in the after-paint signal handler.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1055>
Our internal interpretation of output transforms is not in line with
the Wayland spec. Wayland describes them as the transform that a
compositor will apply to a surface to compensate for the rotation
or mirroring of an output device - counter-clockwise.
Mutter in turn interprets it the other way around. One could
argue it does the same but clock-wise - or it interprets the transform
from the viewpoint of the content, not the device.
In either way, the difference is that 90 and 270 degree values are
switched. Thus swap these accordingly when we translate from
`WL_OUTPUT_TRANSFORM` to `META_MONITOR_TRANSFORM`.
See: https://gitlab.freedesktop.org/wayland/weston/issues/99
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1055>
Since the new ClutterGrab API replaced the old plugin-modal hook,
the event-route is never set to COMPOSITOR_GRAB.
The code in question already checks whether the stage has a grab,
so we can just remove old checks.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
It's not allowed to call eglQueryWaylandBuffer() if the call to
eglBindWaylandDisplay() failed, and will result in an assert being hit
in mesa if called.
Avoid that by keeping track whether we succeeded to bind, and only
attempt to realize a legacy EGL wl_buffer if binding succeeded.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2415>
Simply signal preedit string changes from/to NULL once, in order
to avoid unwanted activity in the client side. We do still need to
send the preedit once each .done event, if there is one, in order
to behave according to the protocol when it matters the most.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2395>
