When the X11 display is actually XWayland there's no point to delay the
compositor selection, given that mutter itself is the compositor and
doing this may cause the first X11 client that starts not to receive the
right information (and in some cases misbehave).
Since some toolkits are not handling the compositor selection changes
properly at later times, let's make their life easier by just
initializing the selection as early as the other X11 properties, given
that in this case there's nothing to replace.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2472
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2970>
Since c390f70edc ("backend: Set up and use ownership chains")
the type of the ClutterInputDevice object's "meta-input-settings-xdevice"
data is `DeviceHandle`, but that commit failed to change the one place
where the object data is queried. As a consequence, that part still
considers it to be an `XDevice`, so everything that uses the return
value of `device_ensure_xdevice()` works with invalid data. Furthermore,
`device_handle_free()` incorrectly uses the `user_data` as the argument
for `XCloseDevice()` leading to a double free.
Fixes: c390f70edc ("backend: Set up and use ownership chains")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2995>
Otherwise binding new wl_output's might try to send enter to the
destroyed resource. Fixes the following crash:
#0 wl_resource_get_client at ../src/wayland-server.c:801
#1 handle_output_bound at ../src/wayland/meta-wayland-surface.c:1287
#3 signal_emit_unlocked_R.isra.0 at ../gobject/gsignal.c:3812
#6 ffi_call_unix64 at ../src/x86/unix64.S:104
#7 ffi_call_int at ../src/x86/ffi64.c:673
#8 ffi_call at ../src/x86/ffi64.c:710
#9 wl_closure_invoke at ../src/connection.c:1025
#10 wl_client_connection_data at ../src/wayland-server.c:438
#11 wl_event_loop_dispatch at ../src/event-loop.c:1027
#12 wayland_event_source_dispatch at ../src/wayland/meta-wayland.c:125
#15 g_main_context_iterate.isra.0 at ../glib/gmain.c:4276
#17 meta_context_run_main_loop at ../src/core/meta-context.c:482
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2196527
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2992>
Otherwise drivers would be free to alter the buffer content. While no
driver is known to do so, it's probably good to make things explicit.
See also `import_simple_dmabuf()` in Weston.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2990>
The DMA buffer paths vs MemFd paths differ slightly in when content is
recorded. This was in some places done by trying to record but bail if
the dequeued buffer had the wrong type. This is problematic for two
reasons: we'd update the timestamp even if we refused to record, making
the follow-up attempt fail, and we'd dequeue and queue buffers that
didn't get any content, meaning the receiving end would see empty
buffers potentially with only cursor updates.
Fix this by keeping track if a stream is DMA buffer able or not, and
don't attempt to record at all in the places we would previously require
DMA buffers. This avoids both issues: we don't dequeue/queue pw_buffers
that we refuse to record to, and we won't update the recorded timestamp
when we didn't intend to record to begin with.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2783
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2987>
This aims to reduce the amount of pixels that have to be redrawed on the
screen on a clipped actor redraw in case using the union of two
different clips in a surface will substantially increase the redrawn
area.
This should not result in excessive memory consumption as callers of
`clutter_actor_queue_redraw_with_clip` are expected to ensure that the
redraw clip rectangles are adequately deduplicated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2965>
mutter-clutter is a private library that is only used by the shell and
not meant to be ABI/API compatible in between versions, so there's no
need to add padding to classes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2903>
Hides libdisplay-info under a build time default-off flag,
provides provision to parse essential edid parameters with
APIs provided by libdisplay-info. This implementaion increases
readibility, avoids code duplication and decreases complexity
of edid parsing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2642>
We are attempting to show windows that do not yet have a
surface/buffer, this makes GNOME Shell avoid transitions
for these windows.
Since on Wayland X11 windows are also Wayland surfaces,
this check is also valid for these, and is thus made more
generic to also cater for these windows.
Eventually, meta_window_update_visibility() is called
when the surface gets its buffer, so the window can be
neatly animated.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2611
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2975>
This ATM triggers missed .commit events for the window in question,
to be addressed in Xwayland. Since the test does not seem to specifically
rely on this window being CSD, make it a regular window instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2975>
Going for the default GL renderer is known to trigger rendering
artifacts using the NVidia proprietary driver. Since we don't have
too many expectatives about frames being flashy (not to the point
of mandating GL), resort to the cairo renderer in the mean time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2976>
Just like the HDR Metadata property the Colorspace property values only
indicate that the display driver supports signaling certain colorimetry.
It does not indidcate that the sink actually supports processing the
colorimetry. For this we have to look up the colorimetry support in the
EDID.
The default colorimetry is always supported. If we want bt.2020 we might
get either the RGB or YCC variant even if we ask for the RGB variant but
there is nothing we can do about it so let's just pretend it's a driver
issue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2919>
If the used EGL backend supports it. In practice this should currently
only affect the nested backend.
Enabling modifiers can help with app development. An example is
`weston-simple-dmabuf-v4l`, which requires the linear modifier to be
available.
Note that Weston behaves similar already.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2972>
This will be used to extract the resolution and refresh rate from
strings like "1920x1080@60.0" or "1280x720". This aims to replace the
use of the locale dependent sscanf() function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2902>
This is needed by GNOME Shell to remove itself as a input method
implementation during its shutdown sequence. We can't do it ourself
later because at mutters own shutdowns equence, the GNOME Shell
Javascript context has by that time already been teared down.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2934>
This function gets called when a surface state transaction is applied.
Applying a transaction can get delayed, so the Wayland resource may have
already been destroyed when we get here. In that case we cannot send
events, so there's nothing to do.
v2:
* Drop code comment, expand commit log instead. (Jonas Ådahl)
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2737
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2967>
Otherwise we'll have a cursor sprite backed by a surface that no longer
exist. This usually doesn't happen, but can happen in rare situations
related to pointer capability changes Wayland client cursor changes and
hotplugs.
Fixes the following crash:
#0 meta_wayland_buffer_get_resource() at ../src/wayland/meta-wayland-buffer.c:128
#1 realize_cursor_sprite_from_wl_buffer_for_gpu() at ../src/backends/native/meta-cursor-renderer-native.c:1649
#2 realize_cursor_sprite_for_gpu() at ../src/backends/native/meta-cursor-renderer-native.c:1869
#3 realize_cursor_sprite() at ../src/backends/native/meta-cursor-renderer-native.c:1887
#4 meta_cursor_renderer_native_update_cursor() at ../src/backends/native/meta-cursor-renderer-native.c:1100
#5 meta_cursor_renderer_update_cursor() at ../src/backends/meta-cursor-renderer.c:414
#6 meta_cursor_renderer_force_update() at ../src/backends/meta-cursor-renderer.c:449
#7 update_cursors() at ../src/backends/meta-backend.c:328
#8 meta_backend_monitors_changed() at ../src/backends/meta-backend.c:338
#9 meta_monitor_manager_notify_monitors_changed() at ../src/backends/meta-monitor-manager.c:3590
#10 meta_monitor_manager_rebuild() at ../src/backends/meta-monitor-manager.c:3678
#11 meta_monitor_manager_native_apply_monitors_config() at ../src/backends/native/meta-monitor-manager-native.c:343
#12 meta_monitor_manager_apply_monitors_config() at ../src/backends/meta-monitor-manager.c:706
#13 meta_monitor_manager_ensure_configured() at ../src/backends/meta-monitor-manager.c:779
#14 meta_monitor_manager_reconfigure() at ../src/backends/meta-monitor-manager.c:3738
#15 meta_monitor_manager_reload() at ../src/backends/meta-monitor-manager.c:3745
or the following on gnome-43:
#0 meta_wayland_surface_get_buffer at ../src/wayland/meta-wayland-surface.c:441
#1 meta_cursor_sprite_wayland_get_buffer at ../src/wayland/meta-cursor-sprite-wayland.c:83
#2 realize_cursor_sprite_from_wl_buffer_for_gpu at ../src/backends/native/meta-cursor-renderer-native.c:1612
#3 realize_cursor_sprite_for_gpu at ../src/backends/native/meta-cursor-renderer-native.c:1836
#4 realize_cursor_sprite at ../src/backends/native/meta-cursor-renderer-native.c:1854
#5 meta_cursor_renderer_native_update_cursor at ../src/backends/native/meta-cursor-renderer-native.c:1087
#6 meta_cursor_renderer_update_cursor at ../src/backends/meta-cursor-renderer.c:413
#7 meta_cursor_renderer_force_update at ../src/backends/meta-cursor-renderer.c:448
#8 update_cursors at ../src/backends/meta-backend.c:344
#9 meta_backend_monitors_changed at ../src/backends/meta-backend.c:354
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2185113
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2968>
Under certain conditions a stage-view update does not trigger a kms
update.
In such cases we still want the next update to run within the same
refresh cycle, as otherwise we'd waste the remaining time in the
current one.
At the same time we currently use the `after-update` signal for Wayland
frame events, which again may result in more "empty" updates -
creating an unthrottled feedback loop. This can trigger excessive
load both in the compositor as well as in clients.
Introduce a new GSource that is dispatched once per refresh cycle at
maximum per stage view and use it to emit frame events. Do so by
computing the time from when on we can be sure that an update resulting
from a client commit would certainly get scheduled to the next refresh
cycle.
Note: this only works on the native backend. Given that chances are
small that we hit the corresponding issue on e.g. the nested backend,
stick to the previous behavior there for now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2823>
It will be used to schedule Wayland frame events independently from both
update and presentation time, as the former may happen multiple times
frame and the later not at all.
For frame events we want a timing that is just late enough to ensure
that a following commit by a Wayland client will not get included into
the current frame any more.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2823>
