Use clearer memory management for the MetaFrame making it easier
to destroy it.

Since we listen the X events in the same thread, and they are delivered
through the main loop, there's not any need to set the frame details on
windows before the reparent operation, because such action could fail.

So move the code order, as preparation for handling the error.

In some cases, reparenting a window with its frame may fail; this seems
to happen especially during initialization of a window that may be
unmapped and re-mapped quickly and multiple times.

If this happens, we're never going to receive a remove event on the
stack tracker and so we may end up adding it twice to the list of the
windows to synchronize with the compositor, breaking its assumption that
the stack list is unique, and eventually leading to a crash because we
do not end up removing all the instances of a window on its destruction.

In particular we may end up in this situation:

  Syncing Window 10485927: 0x555558863540 (actual xid is 10485927),
    user time is 10485928 frame is 0x5555588715c0, frame xid 6291591
  Syncing Window 14680081: 0x5555588664b0 (actual xid is 14680081),
    user time is 14680082 frame is 0x555558871d80, frame xid 6291595
  Syncing Window 6291460: 0x55555796dc80 (actual xid is 10485763),
    user time is 10485764 frame is 0x555557a6f630, frame xid 6291460
  Syncing Window 6291465: 0x555557a68af0 (actual xid is 14680067),
    user time is 14680068 frame is 0x555557a73e80, frame xid 6291465
  Syncing Window 6291509: 0x555557f9d830 (actual xid is 8388623),
    user time is 0 frame is 0x555557fac780, frame xid 6291509
  Syncing Window 6291586: 0x5555586e1690 (actual xid is 4194363),
    user time is 0 frame is 0x55555886e550, frame xid 6291586
  Syncing Window 6291591: 0x555558863540 (actual xid is 10485927),
    user time is 10485928 frame is 0x5555588715c0, frame xid 6291591

Where the same meta window 0x555558863540 is added twice because that's
both mapped by the window itself (10485927) and by its frame (6291591).

This happens because for historical reasons the xids hash table managed
by the x11-display maps both the X11 windows, their frames and their
user time windows as the meta-window, and so if we don't filter out them
properly we end up duplicating the entries in the compositor list.

Such duplicates finally end up making mutter to crash in
meta_compositor_sync_stack() because we could end up trying to access
to an invalid window, given its actor has been destroyed but not all the
instances have been removed from the compositor windows list:

  0x00007ffff71059 in meta_compositor_sync_stack (compositor=0x555555b8,
  stack=0x555558701b80) at ../../mutter/src/compositor/compositor.c:773
  773	          if ((old_window->hidden || old_window->unmanaging) &&
  (gdb) print old_window
  $1 = (MetaWindow *) 0x0

So, in order to prevent this, check that XReparentWindow does not fail,
and in case of failure, reset the window state to the one it had before
we failed and more importantly, remove the association between the frame
X11 window and the MetaWindow, since this is not true anymore and so
that at the next stack synchronization there won't be any meta window
associated to that frame XID (unless there aren't further stack changes
impacting on that). Without this we would have instead waited for the
remove event that we predicted, but that could never happen because no
ReparentNotify is emitted in such case.

Avoid changing the stack information if we fail earlier than that

If the presentation time isn't known, e.g. if the monitor is virtual and
the actual presentation happens far away, the presentation time we
actually received tends to be the time a frame was presented to the next
layer, meaning practically immediately after painting.

When scheduling another update after that, don't assume that if the next
calculated update is not the immediate next update, schedule an update
sooner, as that will in such cases always be true, meaning we ended up
busy looping with constant frame updates being scheduled.

Fix this by only triggering that logic if the last presentation time was
actually vsync:ed.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3803>

Allow a screen cast stream source to say that nothing changed in terms
of cursor metadata, and treat this together with a cursor-only frame as
we not recording anything.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3803>

If we're doing a cursor-only update, only actually do it if anything
changed relative to the stream itself.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3220
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3803>

If we're doing a cursor-only update, only actually do it if anything
changed relative to the stream itself.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3803>

If we're doing a cursor-only update, only actually do it if anything
changed relative to the stream itself.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3803>

If we're doing a cursor-only update, only actually do it if anything
changed relative to the stream itself.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3803>

So they don't need to be installed system-wide before build testing
can work.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3368

(cherry picked from commit b684b5cf)

Michel Dänzer authored Jun 25, 2024 and Robert Mader committed Jun 26, 2024

This is currently redundant, but will be needed with the next commit.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3840>

(cherry picked from commit 03f3c18d)

Michel Dänzer authored Jun 25, 2024 and Robert Mader committed Jun 26, 2024

This ensures that sub-surfaces remain visible during the fade-out
animation of their window.

Fixes: be4bf8da ("wayland/surface: Keep applied sub-surface branch node linked up")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3508
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3840>

(cherry picked from commit fab78d95)

This caused https://gitlab.gnome.org/GNOME/mutter/-/issues/2616.

This reverts commit 2a62e690.

Depending on whether the input mapper was found, these variables could
indeed be used uninitialised, so this is a true positive warning.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3770>
(cherry picked from commit ca1434ff)

Since the `switch` didn’t have a default case, the `cull_front` and
`cull_back` variables could technically be used uninitialised if the
`cull_mode` was unrecognised.

That seems unlikely to happen as presumably other code makes sure the
`cull_mode` is valid, but it doesn’t hurt to add a `default:` case to
squash the compiler warning.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3770>
(cherry picked from commit 173332e9)

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3788>
(cherry picked from commit c33a02dd)

We were leaking the session managers list, but at this point I feel it
looks cleaner to also own it fully

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3788>
(cherry picked from commit f74a46d9)

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3788>
(cherry picked from commit ce1dd40f)

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3788>
(cherry picked from commit c2cc26b3)

We were leaking the color profile path keys but also it wasn't clear how
the ownership was passed to the new hash-table, so let's just remove it
from the pending hash table and add it to the new one including the
expected reference.

This is safe because we were still adding a temporary extra ref to the
profile

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3788>
(cherry picked from commit 430e55a5)

Just steal from the hash table all the times, and use autopointers
to cleanup if needed

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3788>
(cherry picked from commit de8691c7)

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3788>
(cherry picked from commit b630c3ba)

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3788>
(cherry picked from commit 6a04ea9a)

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3788>
(cherry picked from commit 0fda3ab8)

We were leaking one instance because _cogl_winsys_egl_context_created()
could be potentially be called twice (via cogl_display_setup() one as
part of cogl_renderer_check_onscreen_template() and the other when
called from clutter_backend_do_real_create_context()), and so we'd ended
up overwriting the reference we had.

However, we really didn't use it anywhere and once used to call the
relevant functions it's just useless.

So let's just keep it as local variable

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3788>
(cherry picked from commit bcec6df7)

In the shell side we ended up calling the wrong function [1] and mutter
didn't stop us from doing it, so add some type-check guards to ensure we
don't do similar errors again

[1] https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3355

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3791>
(cherry picked from commit 467746c8)

Replace the sync_focus() calls with a set_focus() do-it function taking
a surface. This is in line with the rest of the things that happen at
the default MetaWaylandEventInterface.focus implementation, and will
make these correctly observe the presence of grabs, since
meta_wayland_seat_get_input_focus() will return the would-be focus
in these cases.

This change makes the "focused" client selection truly
in sync with the keyboard focus.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3498
Fixes: 9bdb00c4 ("wayland: Follow seat's input focus client for primary selections")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3789>
(cherry picked from commit 9dab806a)

Replace the sync_focus() calls with a set_focus() do-it function taking
a surface. This is in line with the rest of the things that happen at
the default MetaWaylandEventInterface.focus implementation, and will
make these correctly observe the presence of grabs, since
meta_wayland_seat_get_input_focus() will return the would-be focus
in these cases.

This change makes the "focused" client selection truly
in sync with the keyboard focus.

Fixes: 5ca10c31 ("wayland: Follow seat's input focus client for clipboard selections")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3490
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3789>
(cherry picked from commit b968796f)

This reverts commit 743fb6df.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3789>
(cherry picked from commit ad60d712)

Prior to the grabs/focus rework in !3420, Wayland grabs were handled
separately from ClutterGrabs. This required explicitly checking for
ClutterGrabs as those were expected to prevent events from reaching
Wayland clients.

Now after !3420, Wayland client grabs also result in ClutterGrabs, which
means that this check causes input events for popups with grabs to not
get sent to ibus anymore. Instead the events are getting sent to the
client directly, which results no ibus support in popups (unless the
client handles that itself by using a different GTK_IM_MODULE).

However due to the changes from !3420 checking for ClutterGrabs is also
no longer necessary and the meta_wayland_text_input_update() focus check
is now sufficient to only forward events to ibus, when the focus is
actually on a Wayland client. So to fix this we can simply remove the
check.

Fixes: 2a584a8f ("wayland: Make use of Wayland event grabbing mechanism")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3502
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3787>
(cherry picked from commit a99e139a)

These actors are expected to be destroyed along with their surface, this
however happens later in the process, so there is a moment where actors
are eligible for picking, but do not have a surface anymore.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3729>
(cherry picked from commit 17dc9393)

When unmapping a subsurface, it does lose early its connection to the
parent surface. This is however a deciding factor in determining whether
the surface (role) has a window.

Make the subsurface actor unreactive if its connection to the parent
MetaWindow was severed, since it should not be eligible for picking anymore.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3729>
(cherry picked from commit 66e23b00)

While it should not be expected that we pick the pointer into a
MetaSurfaceActor that is disembodied of its MetaWaylandSurface/MetaWindow,
the paths where this should be enforced are somewhat scattered.

So account for the situation in picking code, and prefer a NULL surface
over a crash. This operates on the assumption that this inconsistent state
where Mutter didn't know better to pick a correct surface actor will be fixed
by later crossing events resolving the intermediate state, and that no
other input events will be received meanwhile.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3393
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3729>
(cherry picked from commit e731f2a0)

Don't try to find the card, and then the render node from it, just ask
udev to list the render nodes directly. This avoids running into
permission errors when the user cannot open /dev/dri/card* even without
mode setting capabilities.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3805>
(cherry picked from commit 6bd2fd6a)

We're not doing anything significant in the KMS thread anyway, so don't
make it a kernel thread, and don't ask to be real time scheduled (which
we wouldn't be anyway, but for clarity).

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3805>
(cherry picked from commit 5bca7611)

Due to a copy and paste error, buttons were not released when the device
was removed.

Found by Coverity.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3809>
(cherry picked from commit 4ae305f1)

Wayland tests also get kvm and tty test variants, but running tty tests
on your main session makes them fail. The intention for tty tests is to
skip when not run from a tty, so fix that.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3811>
(cherry picked from commit 6d8c93ba)

Such as "default" for legacy X11 themes.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3454
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3718>
(cherry picked from commit 847f0150)

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3718>
(cherry picked from commit 13b2803a)

To aid loading of legacy cursor themes.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3718>
(cherry picked from commit 4a4ab8c5)

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3184
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3718>
(cherry picked from commit d2c6b770)

For X11 apps that don't specify their own.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3403
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3718>
(cherry picked from commit 807c99fc)

When mutter creates a dma-buf buffer for screencasting, the buffers
stride will, among other attributes, also be defined.
However, mutter currently only sets the buffer stride, when actually
recording a frame, but not when adding it.
This behaviour disallows screencast consumers (clients) to already
import the respective buffer (i.e. for Vulkan creating a VkImage for the
dma-buf image), as the stride is not yet communicated to the client.

Since the stride won't change after adding the respective buffer,
directly set the buffer stride, when adding the PipeWire buffer. This
allows screencast consumers (clients) to do optimizations in their
encoding paths.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3827>
(cherry picked from commit 0dd40805)

Right now the unmapped signal doesn't always fire which means we didn't
see a surface that's being unmapped in these code paths before. In
particular the resource, window and role can be gone. Handle those
cases.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3783>
(cherry picked from commit 3e7b1d9c)

This was the intention anwyway but it didn't work properly because
GObject::dispose removes all signal handlers and we unmap surfaces in
WaylandShellSurface::finalize. Move all the unmanaging and unmapping to
the dispose vfunc where we can still run all the signal handlers.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3501
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3783>
(cherry picked from commit 4eacf976)

The committed state can't have any children sub-surfaces either, so
just bail.

Fixes: ae403f2e ("wayland: Use new highest scale monitor tracking for fractional_scale_v1")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3552

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3849>
(cherry picked from commit 94f3bbd9)

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3845>
(cherry picked from commit f214eb51)

clutter_input_focus_set_surrounding() expects cursor and anchor positions
to be provided in character offsets.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3440
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3719>
(cherry picked from commit 4b141169)

If the titlebar of a window has been moved above the screen by a user
via an unconstrained move, then any constrained user resize following
this move will cause the window to jump below the top of the screen or
cause other glitchy behavior.

This commit removes the constraint that the titlebar of a window must be
below the top of the screen for any resize that is both (1) triggered by
a user and (2) is a resize that affects only the left, right, or bottom
edges of the window.  This allows users to move a window partially above
the screen and then resize the window to be wider or resize the bottom
edge of the window to make it taller or shorter.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1206
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3764>
(cherry picked from commit 5ba364a9)

The two dialog creation virtual functions returned by these functions have to
be unreferenced by the caller (and are actually unreferenced in other places in
the code).

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3790>
(cherry picked from commit 4134d127)

Update NEWS.

When cloning an actor we were applying a global scale to it, based on
the size of the clone itself and of the cloned actor.

This implied that the transformed size of the clone was not the one that
was set, but it was taking taking in account the actor scaling too.
So in practice we were scaling it twice.

While this had no visual implications it indeed was causing troubles
when a ClutterClone was reactive because in such case only the scaled
area of the scaled clone was considered reactive.

Assume you had an actor of 100x100 pixels, scaling it to a clone of
50x50 pixels:
 - The scale applied to the clone was 0.5
 - The transformed size of the clone was: 25x25 pixels
 - The clone was reactive only in that sub-area

To avoid this, never touch the clone transformation matrix, but only
transform it at paint time.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2959>

(cherry picked from commit 44c0c311)

Michel Dänzer authored Jul 02, 2024 and Robert Mader committed Jul 03, 2024

Thawing Xwayland surfaces don't hit meta_window_actor_wayland_set_frozen,
so we need to sync actor state for them here.

v2:
* Guard META_IS_XWAYLAND_SURFACE by HAVE_XWAYLAND, fixes Wayland-only
  build.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3557
Fixes: ec5444f5 ("wayland/actor-surface: Don't sync actor state for frozen actors")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3862>

(cherry picked from commit 041a404b)

Update NEWS.