Intended to be used by tests, as animations may interfere with testing.
Eventually, a dedicated test plugin should be added, but it is out of
scope for this branch.

Animations may interfere with test cases, e.g. by triggering relayouts,
repaints, when not expected. Disable them, so that more precise test
cases can be added.

If one would end up with an actor attached to mapped actor, where the
attached actor doesn't itself have an up to date stage view list while
listening on the stage for updating, when clearing the stage views of
the list, anything that would query the stage views list at this time
would end up accessing freed memory.

This could happen if

 1) An actor was added to a newly created container actor attached to
    the stage
 2) The actor got a timeline attached to it
 3) The actor was moved to a container that already was mapped
 4) A hotplug happened

After (1) both the container and actor would not have any stage views.
After (2) the timeline would listen on the stage for stage views
updates. After (3) the actor would still listen on the stage for stage
views updates. When (4) happened, the actor would be signalled when the
stage got its stage view cleared, at which point it would traverse up
its actor's tree finding an appropriate stage view to base its animation
on. The problem here would be that it'd query the already mapped
container and its yet-to-be-cleared stage view list, resulting in
use-after free, resulting in for example the following backtrace:

  0)  g_type_check_instance_cast ()
  1)  CLUTTER_STAGE_VIEW ()
  2)  clutter_actor_pick_frame_clock ()
  3)  clutter_actor_pick_frame_clock ()
  4)  update_frame_clock ()
  5)  on_frame_clock_actor_stage_views_changed ()
  6)  g_closure_invoke ()
  7)  signal_emit_unlocked_R ()
  8)  g_signal_emit_valist ()
  9)  g_signal_emit ()
  10) clear_stage_views_cb ()
  11) _clutter_actor_traverse_depth ()
  12) _clutter_actor_traverse ()
  13) clutter_actor_clear_stage_views_recursive ()
  14) clutter_stage_clear_stage_views ()
  ...

Avoid this issue by making sure that we don't emit 'stage-views-changed'
signals while the actor tree is in an invalid state. While we now end up
traversing tree twice, it doesn't change the Big-O notation. It has not
been measured whether this has any noticible performance impact.

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

When a docking station is disconnected, a few previously existing DRM
connectors may now be gone. When this happens, getting them via the
libdrm API results in NULL pointers returning, and we need to handle
this gracefully by making sure the connector state is properly updated.

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

Change a few early-outs to handle the state changes without returning.
This means we'll get to log the result in all cases, which might help
debugging.

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

If some connectors disappeared, but the rest didn't change, we missed
actually removing the ones that disappeared, as we incorrectly assumed
nothing changed. Fix this by only assuming nothing changed if 1) we
didn't add any connector, and 2) we have the same amount of connectors
as before the hotplug event. The connector comparison checking makes
sure we report changes if anything of the still available connectors
changed.

Fixes: a8d11161
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2007
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2097>
(cherry picked from commit cbdd62c1)

We set it via setenv(), and might not have the MetaX11Display at hand.
This fixes a crash when the stuck-client dialog (using zenity) appears
without any X1 client having appeared.

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

It was named the same as the callback function itself, which was
confusing. ADd the `_id` suffix, which is the convention.

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

When an activation times out, we'll be signalled two signals on the
startup sequence object: "timeout", and "complete".

Normally, the "complete" signal is emitted when a startup sequence is
completed succesfully by it being used for activation, and in this case,
the xdg_activation implementation should remove the sequence from the
startup notification machinery.

However, in the timeout case, we should not remove it, as the startup
notification machinery itself will deal with this. If we would, we'd end
up with use-after-free issues, as the sequence would be finalized when
removed the first time.

To avoid this, just clean up the Wayland side in the "timeout" signal
handler, leaving the "complete" signal handler early out if it was
already handled by it.

This avoids crashes like:

  0) g_type_check_instance (type_instance=type_instance@entry=0xdd6740)
  1) g_signal_handlers_disconnect_matched (instance=0xdd6740, ...)
  2) meta_startup_notification_remove_sequence (sn=0x4cc890,
                                                seq=0xdd6740) at
       ../src/core/startup-notification.c:544
  3) startup_sequence_timeout (data=0x4cc890, ...) at
       ../src/core/startup-notification.c:504
  4) g_timeout_dispatch (...) at ../glib/gmain.c:4933

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

Use G_SOURCE_CONTINUE and G_SOURCE_REMOVE intead of TRUE and FALSE.

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

Makes it easier to run it, as one doesn't need to wait for all the other
unit tests.

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

A client can create a token without any seat, serial, or surface. In
this case, we'd still try to grab, which would run into some unforseen
code paths, potentially resulting in the following crash:

  0) meta_wayland_tablet_seat_device_added (tablet_seat=0x55dff4271c90,
                                            device=0x7f87b80655b0) at
       ../src/wayland/meta-wayland-tablet-seat.c:200
  1) meta_wayland_tablet_seat_new (seat=0x0, manager=0x55dff3ec7b40) at
       ../src/wayland/meta-wayland-tablet-seat.c:283
  2) meta_wayland_tablet_manager_ensure_seat (manager=manager@entry=0x55dff3ec7b40,
                                              seat=seat@entry=0x0) at
       ../src/wayland/meta-wayland-tablet-manager.c:239
  3) meta_wayland_tablet_manager_ensure_seat (seat=0x0, manager=0x55dff3ec7b40) at
       ../src/wayland/meta-wayland-touch.c:595
  4) meta_wayland_seat_get_grab_info (seat=0x0, surface=0x55dff43ff5b0,
                                      serial=0, require_pressed=0, x=0x0, y=0x0) at
       ../src/wayland/meta-wayland-seat.c:479
  5) activation_activate (...) at
       ../src/wayland/meta-wayland-activation.c:261

Fix this by not trying to grab if not enough parameters was passed when
creating the token. Also add a test case that reproduces the above
crash.

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

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>
(cherry picked from commit 27ce8496)

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>
(cherry picked from commit 838d5656)

Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2049>
(cherry picked from commit 7c6fe21d)

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

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>
(cherry picked from commit 8fc1325e)

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>
(cherry picked from commit ac907119)

It was dropping to zero after the first frame because it hadn't been
incremented high enough. So the second frame would crash with:
```
  #0 g_type_check_instance_cast
  #1 META_DRM_BUFFER
  #2 copy_shared_framebuffer_cpu
```
That's the CPU-copy path (fallback-fallback) that probably no one is using
but it does work after this fix. Exactly the same issue as was fixed
in `copy_shared_framebuffer_primary_gpu` by 36352f44.

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


(cherry picked from commit acadf5b3)

Michel Dänzer authored Nov 26, 2021 and Robert Mader committed Nov 26, 2021

This can happen if a texture was newly assigned to the actor, but the
unobscured region hasn't been updated yet. Without bailing here, the
actor would display correctly via direct scanout, but other parts of
mutter would continue considering it obscured, which would e.g. result
in no frame callbacks getting sent for its surface.

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

(cherry picked from commit 2c701205)

Jonas Ådahl authored Sep 06, 2021 and Robert Mader committed Nov 26, 2021

On a KMS backed CRTC, hardware cursor are supported when there are
cursor planes to assign them to. Note that when using legacy mode
setting, fake cursor planes are added when adequate.

On virtual CRTCs, used with virtual monitors, the equivalent of hardware
cursor are always supported, as they are sent using embedded PipeWire
stream metadata.

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

(cherry picked from commit e82685d0)

Jonas Ådahl authored Sep 06, 2021 and Robert Mader committed Nov 26, 2021

The cursor renderer shouldn't assume all the CRTCs of a logical are KMS
CRTC's, as we'll end up checking hardware capabilities for CRTC's of
virtual monitors as well, when they were created to not embed the cursor
image directly in the framebuffer.

Instead, use the newly introduced API for checking CRTC cursor
capabilities. This fixes a crash with the following backtrace:

 0) get_plane_with_type_for at ../src/backends/native/meta-kms-device.c:150
 1) meta_kms_device_get_cursor_plane_for at ../src/backends/native/meta-kms-device.c:173
 2) has_cursor_plane at ../src/backends/native/meta-cursor-renderer-native.c:678
 3) foreach_crtc at ../src/backends/meta-logical-monitor.c:247
 4) meta_monitor_mode_foreach_crtc at ../src/backends/meta-monitor.c:1920
 5) meta_logical_monitor_foreach_crtc at ../src/backends/meta-logical-monitor.c:274
 6) crtcs_has_cursor_planes at ../src/backends/native/meta-cursor-renderer-native.c:718
 7) should_have_hw_cursor at ../src/backends/native/meta-cursor-renderer-native.c:881
 8) meta_cursor_renderer_native_update_cursor at ../src/backends/native/meta-cursor-renderer-native.c:1085
 9) meta_cursor_renderer_update_cursor at ../src/backends/meta-cursor-renderer.c:411

Related: https://bugzilla.redhat.com/show_bug.cgi?id=2000183
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1991>

(cherry picked from commit 00c329a2)

Daniel van Vugt authored Nov 22, 2021 and Robert Mader committed Nov 26, 2021

Previously we chose to only anti-alias texels inside the boundary
(`clip_radius - 1.0`) but zoomed in you could see it was slightly smaller
than the correct curve (#2024).

Similarly if you choose to only anti-alias texels outside that edge
(`clip_radius + 1.0`) then you'd get an overly convex curve that doesn't
match up with the straight line sections.

So now we anti-alias texels that intersect the circle boundary, regardless
of which side they are mostly on. For efficiency we define "intersect" to
mean any texel whose center is within 0.5 of the theoretical edge.

Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2024
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2102>

(cherry picked from commit 858b5c12)

Also change all the deprecated allow-none into optional or nullable.



(cherry picked from commit 62ab4c09)

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

Systems with AMD GPUs do not take advantage of Mutter's zero-copy path
when driving DisplayLink screens. This is due to a very slow CPU access
to the zero-copy texture. Instead they fall back on primary GPU doing a
copy of the texture for fast CPU access. This commit accelerates texture
copy by working through damage regions only.

Tests on a 4K screen with windowed applications show significant
reduction of GPU utilisation.

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

This avoids the following crash, that could happen in certain rare race
conditions, e.g. in tests:

  0) wl_closure_invoke (closure=0x2fbf9e0, target=0x2e5b3d0, opcode=0)
     at ../src/connection.c:1014
  1) wl_client_connection_data () at ../src/wayland-server.c:432
  2) wl_event_loop_dispatch () at ../src/event-loop.c:1027
  3) wayland_event_source_dispatch () at ../src/wayland/meta-wayland.c:104
  4) g_main_dispatch () at ../glib/gmain.c:3381

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


(cherry picked from commit 7b83735a)

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


(cherry picked from commit d5f2ec6f)

The matrix and aspect ratio of the tablet is irrelevant on pads, and
it actually triggers warnings when trying change that on those devices:

gnome-shell:42536): mutter-CRITICAL **: 17:22:41.994: meta_input_device_native_get_mapping_mode_in_impl: assertion 'device_type == CLUTTER_TABLET_DEVICE || device_type == CLUTTER_PEN_DEVICE || device_type == CLUTTER_ERASER_DEVICE' failed

This is unnecessary to do on pad devices, these just need to be moved
together with their respective stylus.

(cherry-picked from commit 04eda556)

Non-display-attached tablets (e.g. Intuos) may find no match, which
should mean "use the span of all monitors", not "pick one for me".
Reserve this fallback to touchscreen devices, since these might
still benefit from it.

(cherry-picked from commit e3702c8b)

This is a strange thing to do since MetaInputMapper also does take care of
devices with an output configured through settings, since we might have
devices that were configure through settings exclude other devices that
belong together with an output (e.g. a display-integrated tablet).

This was essentially here as a last resort to avoid matching two very
similar looking tablets to one of two very similar looking outputs. There
was a 50% chance already that the choice was wrong, and now these devices
can all be configured specifically through settings, so this shouldn't
be missed either.

(cherry-picked from commit 67a27a82)

Update NEWS.

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