It's now a signal emitted when `meta_output_set_backlight()` is called.
It is also no longer normalized between 1 and 100; that is now handled
done via the D-Bus API layer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3861>
Add new param to request SyncTimeline metadata on buffer that contains
the sync points.
Add new Buffers param depending on the SyncTimeline metadata and that
adds extra space for the syncobj fd.
When we receive a buffer from PipeWire with the SyncTimeline, also set
up the spa_data with the syncobj fd and the sync type. We use the
GenericFd type.
When we render a buffer with SyncTimeline, set the acquire & release
points for the syncobj.
[ Michel Dänzer:
* Flesh out Wim's skeleton and make it compile
* Dequeue explicit-sync buffers only if the release point has signaled
* Tweak commit log
v2:
* Always check spa_buffer->n_datas as well when getting the
SPA_META_SyncTimeline metadata (Doğukan Korkmaztürk)
* Always put space before opening parens.
v3:
* Keep a per-stream list of dequeued buffers with unsignaled release
point. (Wim Taymans)
* Fix indentation of meta_drm_timeline_is_signaled parameters in
dequeue_pw_buffer.
v4:
* priv->dequeued_buffers handling fixes in dequeue_pw_buffer.
v5:
* Fix bumping sync points in maybe_set_sync_points.
v6:
* Guard new code by #ifdef HAVE_NATIVE_BACKEND as needed.
* Remove unused sync_fd in dequeue_pw_buffer.
v7: (Sebastian Wick)
* Refactor can_reuse_pw_buffer helper out of dequeue_pw_buffer.
* Separate loops for priv->dequeued_buffers and pw_stream_dequeue_buffer
in dequeue_pw_buffer.
* Add g_assert after g_hash_table_lookup.
* Prevent calling meta_drm_timeline_is_signaled with non-NULL *error.
* Use g_autoptr & g_steal_pointer for timeline in maybe_create_syncobj.
* Log meta_drm_timeline_create_syncobj / meta_drm_timeline_import_syncobj
errors in maybe_create_syncobj.
* Use g_warning_once instead of g_warning.
* Do not close (spa_buffer->datas[1].fd) in on_stream_remove_buffer,
g_hash_table_remove closes it.
v8:
* Fix pw_stream_dequeue_buffer loop condition in dequeue_pw_buffer.
(Sebastian Wick)
* Use g_clear_error in can_reuse_pw_buffer. (Sebastian Wick)
* Add comment above dequeued_buffers list declaration in
MetaScreenCastStreamSrcPrivate.
v9:
* Call g_clear_error from dequeue_pw_buffer instead of
can_reuse_pw_buffer. (Sebastian Wick)
v10: (Jonas Ådahl)
* Move added #includes to separate HAVE_NATIVE_BACKEND block.
* Add and use enum entries for spa_buffer::datas array access.
* Clean up the end of can_reuse_pw_buffer.
* Change first argument of dequeue_pw_buffer to MetaScreenCastStreamSrc.
* Rename GSList iterator to "l".
* Clean up error handling in dequeue_pw_buffer.
* Fix second parameter to second can_reuse_pw_buffer call in dequeue_pw_buffer.
* Fix coding style of code added in on_stream_param_changed.
v11:
* Move local_error declaration inside HAVE_NATIVE_BACKEND in
dequeue_pw_buffer.
v12: (Jonas Ådahl)
* Use new syncobj_data_from_buffer helper to retrieve acquire/release
spa_data.
* Generally assume spa_buffer->n_datas is large enough, just spot-check
it in strategic places.
* Use GList for dequeued_buffers list.
* Warn in meta_screen_cast_stream_src_dispose if dequeued_buffers list
isn't empty.
v13:
* Simplify empty list test in meta_screen_cast_stream_src_dispose.
(Jonas Ådahl)
v14:
* Refactor maybe_remove_syncobj helper out of on_stream_remove_buffer.
This allows using g_return_if_fail in the former. (Sebastian Wick,
Jonas Ådahl)
v15:
* Guard syncobj_data_from_buffer & enum definitions by
HAVE_NATIVE_BACKEND, since they're unused outside of that guard.
]
[ Jonas Ådahl
v16:
* Destroy the timelines hash table after destroying the stream.
* Don't warn when getting timeline data.
* Fix n_datas sanity check condition.
]
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3876>
Build upstream version 1.2.0 for the CI image if needed.
v2:
* Build upstream 1.2.0 tag instead of 1.2.2.
v3:
* Build upstream 1.2.3 tag for CI, it has a needed fix.
v4:
* Enable systemd support in pipewire build. (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3876>
Will be used to look up a MetaDrmTimeline object for a syncobj file
descriptor.
v2:
* Add comment above timelines hash table declaration in
MetaScreenCastStreamSrcPrivate. (Bilal Elmoussaoui)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3876>
v2: (Doğukan Korkmaztürk)
* Use drmSyncobjQuery instead of drmSyncobjTimelineWait.
* Fix libdrm function name in error message.
v3:
* Add separate boolean is_signaled out parameter. (Sebastian Wick)
* Use g_strerror instead of strerror.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3876>
Creates a kernel syncobj and returns a file descriptor representing it.
v2:
* Call drmSyncobjDestroy also after drmSyncobjHandleToFD returns 0, or
we leak the original syncobj reference. (Sebastian Wick)
* Add errno based error messages.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3876>
Allow scale-aware Xwayland clients to scale by an integer scale
themselves, instead of letting them render them at 1x scale and then
scaling up the texture, making it look blurry.
When monitor framebuffers are scaled, this special cases Xwayland and
sends output regions in a way that Xwayland think everything is N times
as large as the logical region, where N is the ceil of the max monitor
scale.
This is done by introducing a "stage" vs "protocol" coordinate space for
X11, where the "protocol" coordinate space is "stage" multiplied by a
scaling factor.
Xwayland thus will have its own "effective scale", sent via
wl_output.scale. The effective Xwayland scale is also used for the
internal MetaWaylandSurface scale internally, unless there is a viewport
dst size set on the same surface, in which case the scale is still set
to 1, to not interfere with wp_viewport semantics.
We're guarding this behind a new experimental feature
"xwayland-native-scaling", which can only come into effect when enabled
together with "scale-monitor-framebuffer".
[v2]:
Move stage_to_protocol/protocol_to_stage to generic window class.
This means parts that aren't aware of any windowing system specific
logic, only that coordinates originate from there for a given window,
can still get their coordinates properly handled.
In particular, this means coordinates from IBus that originates from the
client, can be scaled properly when that client is using X11.
Also make them properly introspected.
[v3]:
Split up coordinate transform API.
Make it one that takes a MtkRectangle, and another that takes a point.
This means the rounding strategy becames explicit when transforming a
point, while when it's a rectangle, it's still always "grow".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567>
This scale is currently a lie, it doesn't do anything. What it
represents is the current highest monitor scale, and will eventually be
used to, when configured to do so, scale X11 coordinates as well as
coordinates given to Xwayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567>
We know let Xwayland set the RANDR names from the connectors. To stop
relying on layouts and coordinates to match the primary logical monitor,
instead use the connector name of the first monitor.
Also make the X11 client sanity checking check that the right X11 output
is primary as part of the monitor tests.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567>
With the next commits we'll introduce a new mode for scaling of Xwayland apps,
we'll want to put this mode behind an experimental setting though, so add
that setting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567>
This replaces the `legacy-ui-scaling-factor` entry in
`org.gnome.Mutter.DisplayConfig`, with the motivation being to no longer
expose X11 specific state via the monitor configuration API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567>
Hooks up the wayland protocol to the color state luminances. The color
state handles the default levels so we can just pass everything through
after we checked for all the error conditions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3953>
This uses the luminance levels of the color states to anchor the white
of content instead of hard-coding the levels.
This also starts using uniforms for parts of the mapping which means we
don't have to generate and compile a shader when the luminance levels
change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3953>
They represent the minimum and maximum luminance levels of the primary
color volume and the reference luminance level (reference white, SDR
white, ...) in the reference viewing environment.
They help anchoring the white level, optionally help with preserving the
dynamic range and help with adjusting from a "dark" to a "bright"
viewing environment.
The values have defaults which depend on the transfer characteristics.
This reflects the wayland color management protocol.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3953>
Actions might get detached sometime during event processing,
at a time that the stage did already prepare an emission chain
holding references to the actions and actors that need to handle
events. This means actions might become detached, but still handle
the incoming event, or possible crossing events generated in-place
when the actor becomes unparented.
Avoid this situation, by skipping event handling on actions that
went detached, we will just instruct to continue event processing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3988>
Hiding it in debug logging was a little too hidden. Someone might want
to know why performance has degraded without having to restart in debug
mode hoping they can reproduce the issue.
Also remove an assertion that would issue spurious warnings. We should not
always expect IMPORT_STATUS_NONE (implying the first failure must be on
the first frame). Instead we might start with IMPORT_STATUS_OK for a number
of frames and then have a sporadic failure some time later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3928>
To expose it, run mutter/gnome-shell with `--debug-control` and then call
`./tools/debug-control.py --enable ColorManagementProtocol`, or set
`MUTTER_DEBUG_COLOR_MANAGEMENT_PROTOCOL=1`.
Co-authored-by: Joan Torres <joan.torres@suse.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3893>
