This was somewhat ineffective since it was applied after figuring out
the x/y absolute coordinates. Change the order (filter first, then
figure out abs coords), and use coordinates from the correct device
while at it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3012>
A failing allocation is non-fatal here, however if it fails later in a
lazy allocation triggered by `cogl_framebuffer_create_timestamp_query()`
we end up crashing. Thus force the allocation early, like we already do
in other places.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3004>
While it's obviously good to trap possible errors from X calls, we are
mixing the Clutter error trap with the MetaX11Display one for these
calls.
This may result in situations where a X call within a Clutter error
trap fails, but it's actually handled in these sections using the
MetaX11Display error trap. This one will consider the serial out
of the "handled" parts and raise an error.
It is better to stay consistent here, and use the same error traps
than the rest of the X11 backend.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2796
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3002>
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 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>
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>
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>
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>
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>
Pass the timestamp of the frame as the target timestamp of the
record. This makes the rudimentary frame throttling mechanism
inside MetaScreenCastStreamSrc work with the timing variability
that dynamic dispatch times introduced.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
Instead of always, unconditionally scheduling an idle callback for
frame recording, try to record a DMA-BUF only frame, and only if
that's not possible, schedule the idle callback.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
When a stream source subclass asks for a DMA-BUF only frame record,
it is legitimate to return FALSE in do_record_frame() - meaning that
a frame was not recorded - but not return an error - meaning nothing
actually failed.
This avoids spamming the journal with warnings on a legitimate case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
Add meta_screen_cast_stream_src_maybe_record_frame_with_timestamp()
which operates on arbitrary timestamps; and make the current function
meta_screen_cast_stream_src_maybe_record_frame() just call into the
new variant, passing g_get_monotonic_time() as the timestamp.
This will be useful later we start using the target timestamp of the
frame for screencasting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
This change will export the damaged regions (when available) out
to the pipewire client. This change is currently specific to
virtual streams only (where I was able to test the change) and
maintains the current behavior for other screencast stream types.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2775>
This change allows clipped redraws for offscreen. The net
effect of this change is to preserve the original redraw clip when
possible (rather than overwriting it with the full view redraw) in
the paint context.
This eventually helps in retrieving the fine grained updated regions of
the frame since last redraw and sending it to the pipewire client
(as shown in a subsquent CL).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2775>
Returning FALSE does not indicate an error, but a valid backlight
value of 0. Consumers expect a negative value to indicate no
backlight support, so return -1 in case of error, just like we
already do for invalid values.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2947>
The unknown color space's only purpose is to signal that the current KMS
state has a unknown color space set. It is not one of the color spaces
that can be set. We already only try to set a color space if the default
color space is supported so we should use the default color space as a
fallback instead of the unknown color space.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2693
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2915>
We might get told to restore the old monitor configuration by the
monitor configuration prompt, in case the user pressed "revert" or
equivalent. This might be in response to a button press, and those
happen during frame clock dispatch. If we would restore an old
configuration during dispatch, it means we would reconfigure the
monitors including their stage views while dispatching, which means we'd
destroy the frame clock while it's dispatching.
Doing that causes problems, as the frame clock isn't expecting to be
destroyed mid-function. Specifically,
We'd enter
clutter_frame_clock_dispatch (clutter-frame-clock.c:811)
frame_clock_source_dispatch (clutter-frame-clock.c:839)
g_main_dispatch (gmain.c:3454)
g_main_context_dispatch (gmain.c:4172)
g_main_context_iterate.constprop.0 (gmain.c:4248)
g_main_loop_run (gmain.c:4448)
meta_context_run_main_loop (meta-context.c:482)
main (main.c:663)
which would first call
_clutter_process_event (clutter-main.c:920)
_clutter_stage_process_queued_events (clutter-stage.c:757)
handle_frame_clock_before_frame (clutter-stage-view.c:1150)
which would emit e.g. a button event all the way to a button press
handler, which would e.g. deny the new configuration:
restore_previous_config (meta-monitor-manager.c:1931)
confirm_configuration (meta-monitor-manager.c:2866)
meta_monitor_manager_confirm_configuration (meta-monitor-manager.c:2880)
meta_plugin_complete_display_change (meta-plugin.c:172)
That would then regenerate the monitor configuration and stage view
layout, which would destroy the old stage view and frame clock.
meta_stage_native_rebuild_views (meta-stage-native.c:68)
meta_backend_native_update_screen_size (meta-backend-native.c:457)
meta_backend_sync_screen_size (meta-backend.c:266)
meta_backend_monitors_changed (meta-backend.c:337)
meta_monitor_manager_notify_monitors_changed (meta-monitor-manager.c:3595)
meta_monitor_manager_rebuild (meta-monitor-manager.c:3683)
meta_monitor_manager_native_apply_monitors_config (meta-monitor-manager-native.c:343)
meta_monitor_manager_apply_monitors_config (meta-monitor-manager.c:704)
After returning back to the original clutter_frame_clock_dispatch()
frame, various state in the frame clock will be gone and we'd crash.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2901>
We have the drm/InfoFrame encoding and our MetaOutputHdrMetadata
encoding. Check that we can correctly convert between each other by
doing a encode/decode and decode/encode roundtrip and then checking for
equality.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
The existence of the KMS property just means that we can send an
InfoFrame but we also have to make sure the sink actually supports the
metadata type 1 and the selected transfer function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
Allows to prepare KMS updates to set the color space and HDR Static
Metadata on the output.
For some reason we need ALLOW_MODESET on commits which change the HDR
Static Metadata InfoFrame on AMDGPU. There is no technical reason why
one needs to mode set to send an InfoFrame and the driver should just
manage without ALLOW_MODESET. Until this is resolved in the kernel we
just prepare KMS updates which might mode set.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
