When using Xwayland-on-demand (default), if the (experimental) autoclose
features is enabled, we can rely on Xwayland's auto-terminate feature
instead of explicitly killing the Xwayland process.
With it, gone is the mechanism that was added to check the X11 clients
connected and their executable to check whether we can (safely) kill
Xwayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794>
The connection to the Xserver for the X11 window manager part of mutter
even on Wayland may prevent the Xserver from shutting down.
Currently, what mutter does is to check the X11 clients still connected
to Xwayland using the XRes extension, with a list of X11 clients that
can be safely ignored (typically the GNOME XSettings daemon, the IBus
daemon, pulseaudio and even mutter window manager itself).
When there is just those known clients remaining, mutter would kill
Xwayland automatically.
But that's racy, because between the time mutter checks with Xwayland
the remaining clients and the time it actually kills the process, a new
X11 client might have come along and won't be able to connect to
Xwayland that mutter is just about to kill.
Because of that, the feature “autoclose-xwayland” is marked as an
experimental feature in mutter and not enabled by default.
Thankfully, the Xserver has all it takes to manage that already, and
is even capable of terminating itself once all X11 clients are gone (the
-terminate option on the command line).
With XFixes version 6, the X11 clients can declare themselves
"terminatable", so that the Xserver could simply ignore those X11
clients when checking the remaining clients and terminate itself
automatically.
Use that mechanism to declare mutter's own connection to the Xserver as
"terminatable" when Xwayland is started on demand so that it won't hold
Xwayland alive for the sole purpose of mutter itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794>
Adding a <dbus/> element containing a boolean (yes/no) determines
whether org.gnome.Mutter.DisplayConfig ApplyMonitorsConfig will be
callable. The state is also introspectable via the
ApplyMonitorsConfigAllowed property on the same interface.
For example
<monitors version="2">
<policy>
<dbus>no</dbus>
</policy>
</monitors>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
The test aims to verify that setting the following policy
<policy>
<stores>
<store>system</store>
</stores>
</policy>
only applies monitor configurations from the system level.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
This adds a way to define a way, at the system level, to define a policy
of how monitor configuration files are loaded.
The intended use case is to e.g. either prefer system level monitor
configurations before user levels, or only allow system level
configurations.
Examples:
Prefer system over user level configurations:
<monitors version="2">
<policy>
<stores>
<store>system</store>
<store>user</store>
</stores>
</policy>
<configuration>
...
</configuration>
</monitors>
Only allow system level configurations:
<monitors version="2">
<policy>
<stores>
<store>system</store>
</stores>
</policy>
<configuration>
...
</configuration>
</monitors>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
strncmp() always return 0 if the passed length is 0. What this means is
that whatever the first string check happens to be, if the parsed XML
cdata was empty (e.g. if we got <element></element>), the first
condition would evaluate to true, which is rather unexpected.
Fix this by making sure the string length is correct first. Also move it
into a helper so we don't need to repeat the same strlen() check every
time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
The way device backends implement power saving differ, and power saving
needs to contain nothing incompatible in the same update. Make it
impossible to e.g. mode set, page flip, etc while entering power save by
not using MetaKmsUpdate's at all for this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
When we're predicting state, i.e. when having posted an update while
avoiding reading KMS state, copy the predicted state, update the actual
state, and check that the predicted state matches the newly updated one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
It was a bit scattered, with it being split between MetaKms and
MetaKmsImpl, dealing with MetaKmsDevice and MetaKmsImplDevice
differentation. Replace this by, for now, single entry point on
MetaKmsDevice: meta_kms_device_process_update_sync() that does the right
thing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
As other KMS tests, depends on being DRM master and vkms being loaded.
Currently consists of a sanity check that checks for the expected set of
connectors, CRTCs, planes, etc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
Right now gamma is set only via the D-Bus API (from gsd-color), but the
actual gamma isn't right after SetCrtcGamma(), meaning if one would call
GetCrtcGamma() right after setting it, one would get the old result.
Avoid this by getting the "current" CRTC gamma from the cache we manage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
In order to support dynamic imports, gjs added an implicit mainloop
that can drive the main context independently from other mainloops
like the one from GApplication or MetaContext.
That means that sources can now get dispatched to the main context
from the moment the plugin is started, resulting in a crash as the
association between compositor and plugin manager doesn't exist until
meta_plugin_manager_new() returns.
Make sure this doesn't happen by only starting the plugin after
meta_plugin_manager_new() has returned.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2242>
When privacy screen is changed and this happens on explicit user request
(that is not a setting change) we should notify about this via an OSD.
To perform this, we keep track of the reason that lead to a privacy
screen change, and when we record it we try to notify the user about.
When the hardware has not an explicit hotkey signal but we record a
change we must still fallback to this case.
Fixes: #2105
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
Privacy screen events on connector are handled as notification events
that won't cause any monitors reconfiguration but will emit monitors
changed on DBus, so that the new value can be fetched.
We monitor the hardware state so that we can also handle the case of
devices with hw-switchers only.
In case a software state is available it means we can also support
changing the state, and if so expose the state as unlocked.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
When both a setting change and a monitor change happens we need to
ensure that the monitor settings are applied.
This is currently only related to privacy settings, but will in future
also handle other monitor parameters such as brightness.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
Some monitors support hardware features to enable the privacy screen
mode that allows users to toggle (via software or hardware button) a
state in which the display may be harder to see to people not sitting
in front of it.
Expose then this capability to the monitor level so that we can get its
state and set it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
In some cases mutter is started in the user scope from a TTY (for
example using toolbox). Using sd_pid_get_session fails because it's not
in the session scope so it falls back to the primary session
(sd_uid_get_display). We want to start mutter on the TTY we started
mutter on however. Instead of relying on the scope to figure out the
correct session we first look at $XDG_SESSION_ID which is set by
systemd_pam.so.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2254>
It is possible that we never create a cached state for a surface
even if it is synced. That is the case if `commit()` is never called.
We still need to call `apply_state()` in this case in order to run
e.g. `role_post_apply_state()` or `parent_state_applied` on subsurfaces.
So just ensure to initialize the cached state instead of bailing out.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2232>
Subsurfaces can be effectively synced indirectly via their ancestors.
Right now such indirectly synced surfaces don't apply their cached
state when their ancestor effectively becomes desync as by the time
we call `parent_state_applied()` on them, they are considered as
desync.
Thus sligthly reoder things so when the ancestors becomes desync
and applies its state, those surfaces still count as synced and
will thus apply their cached state as well.
While on it, add a check to prevent `set_desync()` to have side
effects when the target surface is not currently synced.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2232>
At first glance the `goto` looks like a loop, or potentially an infinite
loop. It's not a loop because the mode has changed at that point to
`META_SHARED_FRAMEBUFFER_COPY_MODE_PRIMARY`. But we can make it more
obvious and avoid the need for a goto.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2240>
The stage window is an interface, that added properties, that were only
then actually managed by MetaStageImpl. Shuffle things slightly, and let
the MetaStageImpl object deal with these things itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2014>
What the keymap eventually is after, are things handled by the actual
backend (MetaBackendX11), so let it keep a pointer to that. This
eliminates some usages of globals.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2014>
It tests that if we go from (x is the pointer cursor)
+--------+
| |
| X |
+--------+
to
+----------------+
| |
| |
+--------+ |
| | |
| X | |
+--------+----------------+
i.e. making sure that X ends up somewhere within the logical monitor
region.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2237>
These will be skipped by default, but can be run from a TTY for easier
debugging by doing:
dbus-run-session -- meson test -C build --suite mutter/native/tty --setup plain
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
This commit makes it possible to run test executables in a test
environment constructed of a virtual machine running the Linux kernel
with the virtual KMS driver enabled, and a mocked system environment
using meta-dbus-runner.py/python-dbusmock.
The qemu machine is configured to use 256M of memory, as the default
128M was not enough for the tests to pass.
Using qemu is also only made possible on x86_64; more changes are needed
for it to be runnable on aarch64, so add a warning if it was enabled on
any other architecture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
This is needed if one wants to run the test suite parts that need KMS or
evdev access in a virtual machine.
However, only initiate these methods if the meta-dbus-runner.py program
was launched with --kvm, as it's only suitable for using while running
as root in a virtual machine.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
When we test, we might not have a systemd session to rely on, and this
may cause some API we depend on to get various session related data to
not work properly. Avoid this issue by passing fallback values for these
when we're running in test mode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
There will be another mode added later, 'test'; prepare for this by
changing the existing "mode" boolean ('headless') to a mode, which is
either 'default' or 'headless'. Checking the is_headless variable is
changed to using the function is_headless(), except for one place, being
VT switching, which in preparation is only allowed on the 'default'
mode. Other places where it makes sense, the conditions are changed to
switch statements.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
When running in KVM, the EGL driver supports querying the render node
path, but it returns NULL. Handle that better by falling back to
querying the device main device file, instead of falling back on v3 of
the protocol and logging a warning.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
Some API will return NULL or the equivalent; sometimes it's an error,
and sometimes it's not, and the way to check that is by looking at the
return value of eglGetError(). When we check this, don't set the GError
if it returned EGL_SUCCESS, as that indicates that the return value is
expected behavior, and not an error.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
There was a sanity check that complained if there was still a "next
framebuffer" when disposing an onscreen. This is correct to complain
about under normal operation, as we always wait until receiving the page
flip callback before cleaning up the onscreen and their state.
However, when there are many hotplugs occurring, we might end up with
race conditions when the above sanity check is not valid: when we have
more than one monitor active, paint 1 one of them, but receive a hotplug
event before we paint the other(s), we will discard the already painted
onscreen before really issuing a page flip.
In this situation, we will have the "next framebuffer", but having that
is not a bug, it's a race condition, thus to not leak in this situation,
make sure to clean up the next framebuffer here too.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2081
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2225>
If there are any pending updates, for example if we painted one of
multiple monitors but without having posted the update due to waiting
for another monitor to be painted, but before we paint all of them and
post the update, another hotplug event happens, we'd have stale pending
KMS update. When that update eventually would be processed, we'd try to
apply out-of-date updates which may contain freed memory.
Fix this by discarding any update when we're rebuilding the views. We
can be sure not to need any of the old updates since we're rebuilding
the whole content anyway.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1928
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2216>
Following the EGL_KHR_swap_buffers_with_damage specification, the
surface damage used by eglSwapBuffersWithDamage does not need to
contain the damage history.
Rework that to reduce the amount of rectangles that get passed to
the backend.
Also rework some of the regions that were using fb_clip_region and
missing the last scaling to support fractional scaling.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2089>
When the before-paint function is executed, it's only purpose
is to check if there's any scanout queue, and immediately
record it if any.
However, since [1], we regressed in this specific case with the
introduction of an idle callback in the before-paint function.
The regression only happens when the PipeWire stream is using
DMA-BUF buffers, and it would operate as follows:
1. In before-paint, when there's a scanout available, we queue
an idle callback to capture the monitor. The idle callback
(almost always) executes after the scanout is pulled from
the stage view
2. meta_screen_cast_stream_src_maybe_record_frame() is called
by the idle callback. In the DMA-BUF case, it then runs
meta_screen_cast_monitor_stream_src_record_to_framebuffer()
3. In meta_screen_cast_monitor_stream_src_record_to_framebuffer(),
because the stage view doesn't have a scanout anymore, it
ends up calling cogl_blit_framebuffer() with the stage view
framebuffer. This is the regression bug.
This regression presents itself in the form of the screencast
stream showing the desktop when there's an unredirected fullscreen
application window running.
Revert before-paint - and only that - back to immediately capturing
any available scanout. Only record these frames when the target
buffer is a DMA-BUF handle. Nothing is captured on before-paint if
the stream is not using DMA-BUF, since the regular paint routine
will handle these frames regularly post-paint.
[1] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1914
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2186>
Next commits will reintroduce a certain behavior of stage
capturing that can only happen with DMA-BUF buffers. To
control this, add a new flag tp MetaScreenCastRecordFlags
for this behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2186>
If a Wayland subsurface is the topmost actor, consider in for
scanout as well. This will extend our scanout capabilities to apps
like Firefox
While on it, correct a unnessary type check to a NULL check.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2211>
On Wayland a window actor may have more than one surface actor,
most importantly when subsurfaces are used.
Add a new function to request the one which is at the top -
it will be used in the next commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2211>
If the EGL header is not new enough, it will not contain that relatively
new macro definition, so to avoid breaking compilation, define it
ourselves for now. Should be possible to remove after some time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2214>
We save the window rect before going fullscreen to a dedicated variable,
so we can go back to the correct dimension. We also have a dedicated
variable for returning from other window states, e.g. maximized, and
this one we initialized when creating the MetaWindow. This meant that we
could always rely on this being up to date on X11 windows that were
mapped maximized or fullscreen.
What the commit that introduced the saved rect dedicated for going
unfullscreen missed was to initialize the new saved rectangle too when
creating the MetaWindow. This resulted in windows mapped as fullscreen
often ending up misbehaving when unfullscreening, as mutter would tell
them to unfullscreen to 0x0.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1786
Fixes: a51ad8f932
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2210>
Since every input stream now uses its own window, the X property used to
transfer the data no longer has to be unique, so we can stop generating
those unique names. This avoids creating a new atom for every transfer
since those are never freed, neither on the shell nor on the server
side. Also don't unnecessarily duplicate other strings that are
(almost) never used and get them from the atom in the rare case when
they are needed.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1328
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1812>
When there are two (or more) concurrent XConvertSelection requests with
the same target, selection and window and the data is large enough for
SelectionNotify events to overlap. This can result in the affected streams
being considered completed without any data being transferred.
While regular mutter/shell code does not make use of concurrent
XConvertSelection requests with the same targets, some extensions might.
Such as for example a clipboard manager that like the built-in clipboard
manager tries to read the selection on owner-changed.
One potential solution would be to make sure the event is for the correct
property, but not all clients seem to support concurrent requests for the
same targets but different properties on the same window.
This commit instead changes the streams to use their own window which
seems to be more widely supported.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4034
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1812>
This is a preparation for each input stream creating its own window. It
moves deleting the property from meta_x11_selection_input_stream_xevent
where it can run after the stream has been finalized to a spot where
the stream still exists. Use an error trap in case the property was not
set by the client, such as when the conversion failed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1812>
This significantly increases the chance of a fullscreen surface buffer
being scanned out instead of being painted via composition. This is
assuming the client supports the DMA buffer feedback Wayland protocol.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2146>
This API can be used to construct a MetaKmsUpdate with plane assignments
that in isolation will be tested against the current KMS state. How it
is tested depends on the KMS implementation; in the simple / legacy KMS
backend, the tests are identical to the current scanout requirements
(dimension, stride, format, modifiers, all must match), and with atomic
KMS, it uses the TEST_ONLY on a real constructed atomic mode setting
commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2146>
Whenever a surface is promoted as a scanout candidate by
MetaCompositorNative, it'll get a CRTC set as the candidate CRTC.
When a client asks for DMA buffer surface feedback, use this property to
determine whether we should send a scanout feedback tranche.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1959>
The final tick of a timeline is >= its duration, but when using ticks that
are slightly in the future ("next presentation time") this means the final
tick will execute and complete the timeline up to one frame interval before
the timestamp of that final tick.
For the single clock test we now just check if the overall duration is
within one frame of the expected timeline duration.
The dual clock (switching) test needs a threshold of two frames because
starting each new clock creates a phase shift (error) of up to one frame.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2161>
We're in the destructor, it's pointless to unset the userdata as we'll
never ever see a request being invoked with it ever again, since the
resource itself will be destroyed or marked as destroyed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2202>
When rendering to a buffer that is not the stage view buffer, we can not
know where the buffer will be displayed on the screen. As a result we
also can not know what translation would need to be applied to culling.
This was causing glitches when the gnome-shell magnifier was applying
offscreen effects. ClutterOffscreenEffect causes MetaWindowGroup to be
rendered to an offscreen buffer at an offset, because it draws to a
slightly larger texture with an accordingly translated origin. This
translation then later is canceled out again when the offscreen buffer
is drawn. To meta_actor_painting_untransformed() however which only sees
the translation used when drawing to the buffer this looked like the
window group was being rendered at the offset. This then lead to
redraw_clip getting translated accordingly, resulting in wrong
coordinates used for culling.
Similarly this was leading to issues when taking area screenshots while
at 1x zoom.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1678
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4876
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2080>
Refresh rates >60Hz become ever more common. In order to allow users
to keep hight refresh rates when not running at a natively advertized
resolution, add common refresh rates to our fallback modes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2189>
Right now we often add a duplicate fallback mode that's almost
identical to the native mode. This adds unnecessary clutter to
UIs, thus filter out such modes.
In order to keep the code small, use `MetaCrtcModeInfo` directly
instead of recalculating the values. And to keep consistency, do
the same in the loop above.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2189>
This is so that it can unregister from it on tear down. The tracker owns
references to cursors too, but this cycle is already broken as the
backend calls 'g_object_run_dispose()' when tearing the cursor tracker
down.
Fixes a crash on shutdown.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2181>
An incorrect assumption that after mode set there would be no pending
page flips was made. This meant that if there was a mode set, followed
by a page flip, if that page flip was for a CRTC on a now unused GPU,
we'd crash due to the renderer GPU data having already been freed. This
commit avoids that by keeping it alive as long as the page flips are
still in the air. It fixes crashes with backtraces such as
0) meta_render_device_get_egl_display (render_device=0x0)
at ../src/backends/native/meta-render-device.c:320
1) secondary_gpu_state_free (secondary_gpu_state=0x1c8cc30)
at ../src/backends/native/meta-onscreen-native.c:560
2) meta_onscreen_native_dispose (object=0x1cb65e0)
at ../src/backends/native/meta-onscreen-native.c:2168
3) g_object_unref (_object=<optimized out>)
at ../gobject/gobject.c:3540
4) g_object_unref (_object=0x1cb65e0)
at ../gobject/gobject.c:3470
5) clutter_stage_view_finalize (object=0x1cbb450)
at ../clutter/clutter/clutter-stage-view.c:1412
6) g_object_unref (_object=<optimized out>)
at ../gobject/gobject.c:3578
7) g_object_unref (_object=0x1cbb450)
at ../gobject/gobject.c:3470
8) meta_kms_page_flip_closure_free (closure=0x1d47e60)
at ../src/backends/native/meta-kms-page-flip.c:76
9) g_list_foreach (list=<optimized out>, func=0x7fb3ada67111 <meta_kms_page_flip_closure_free>, user_data=0x0)
at ../glib/glist.c:1090
10) g_list_free_full (list=0x1cb4d20 = {...}, free_func=<optimized out>)
at ../glib/glist.c:244
11) meta_kms_page_flip_data_unref (page_flip_data=0x1c65510)
at ../src/backends/native/meta-kms-page-flip.c:109
12) meta_kms_callback_data_free (callback_data=0x227ebf0)
at ../src/backends/native/meta-kms.c:372
13) flush_callbacks (kms=0x18e2630)
at ../src/backends/native/meta-kms.c:391
14) callback_idle (user_data=0x18e2630)
at ../src/backends/native/meta-kms.c
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2147>
This ensures we don't have any left over cursor GPU buffers (via
gbm_bo's) after destroying the corresponding gbm_device (owned by
MetaRenderDevice).
Fixes crashes with backtraces such as
1) meta_drm_buffer_gbm_finalize at ../src/backends/native/meta-drm-buffer-gbm.c:450
4) invalidate_cursor_gpu_state at ../src/backends/native/meta-cursor-renderer-native.c:1167
9) update_cursor_sprite_texture at ../src/wayland/meta-wayland-cursor-surface.c:70
10) meta_wayland_surface_role_apply_state at ../src/wayland/meta-wayland-surface.c:1869
11) meta_wayland_surface_apply_state at ../src/wayland/meta-wayland-surface.c:832
12) meta_wayland_surface_commit at ../src/wayland/meta-wayland-surface.c:993
13) wl_surface_commit at ../src/wayland/meta-wayland-surface.c:1158
14) ffi_call_unix64 at ../src/x86/unix64.S:76
15) ffi_call at ../src/x86/ffi64.c:525
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2147>
During tear down, if anything teared down after the seat tries to get
the cursor renderer, we'd crash trying to get it as the seat would
already be gone. Avoid this by returning NULL when there is no seat.
It's assumed that any path that will happen during tear down that relies
on getting the cursor renderer will gracefully handle it not being
present, e.g. by relying on the cursor rendering cleaning up itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2147>
Most clients nowadays switched to buffer damage, most notably Mesa
and Xwayland. Thus lets avoid the extra cost of allocating three
`cairo_region_t`s and doing some calculations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2168>
If no viewport is set, the neutral viewport is the surface size
without viewport destination size applied - i.e. transform and
scale applied to the buffer size. Change it accordingly, giving
us the same values we'd return in `get_width` in this case.
As result, this only changes cases where a viewport destination
size but no viewport source rectangle is set.
The change fixes exactly such cases, e.g. the Gstreamer Wayland
sink. Can be tested with: `gst-play-1.0 --videosink=waylandsink`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2168>
