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>
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>
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>
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>
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>
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>
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>
The GBM support in the NVIDIA driver is fairly new, and to make it
easier to identify whether a problem encountered is related to using GBM
instead of EGLStreams, add a debug environment variable to force using
EGLStream instead of GBM.
To force using EGLStream instead of GBM, use
MUTTER_DEBUG_FORCE_EGL_STREAM=1
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2045
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2132>
Let the meta_cursor_sprite_realize() function return a boolean value
telling whether there was an actual change in the sprite cursor. E.g.
the surface/icon for it changed in between.
This is used in the native backend to avoid converting/uploading again
the cursor surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
MetaBackend can now show whether it is in headless mode or not
using a vfunc is_headless.
Fallback of is_headless returns FALSE.
MetaBackendNative implements is_headless returning its
is_headless property.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2130>
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>
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>
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 36352f44f9.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2104>
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: a8d11161b6
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2007
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2097>
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>
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>
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>
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>
This replaces functionality that MetaRenderDevice and friends has
learned, e.g. buffer allocation, EGLDisplay creation, with the usage of
those helper objects. The main objective is to shrink
meta-renderer-native.c and by extension meta-onscreen-native.c, moving
its functionality into more isolated objects.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
All render devices that have a device file backing them might be able to
allocate dumb buffers, so add a helper for doing that. Will indirectly
result in an error up front on a surfaceless render device due to lack
of a device file.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
It might not be needed by the user of the buffer, so don't always
require it up front. Instead make sure that any user that needs it first
calls "meta_drm_buffer_ensure_fb_id()" to create the ID.
Only the plain gbm implementation creates the ID lazilly, the other
still does it on construction due to the objects used to create them
only existing during construction.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
Mostly calls into gbm_bo_* API, or something somewhat similar when on
dumb buffers. Added API are:
* get offset for plane
* get bpp (bits per pixel)
* get modifier
This will allow users of MetaDrmBuffer to avoid having to "extract" the
gbm_bo to get these metadata.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
The purpose of MetaRenderDevice is to contain the logics related to a
render device; i.e. e.g. a gbm_device, or an EGLDevice. It's meant to
help abstract away unrelated details from where it's eventually used,
which will be by MetaRendererNative and the MetaOnscreenNative
instances.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
