There might not be a single plane that is "for" a CRTC, so remove the
API that made it appear as if it did. The existing users only cared if
there was some plane for said CRTC, so replace the getters with API that
just checks the existance at all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
When there are a set of primary planes, and a set of CRTCs, where each
plane can be used on multiple CRTCs, we need to make sure that when we
mode set and page flip, each CRTC gets assigned an individual plane that
isn't used with any other CRTC.
Do this during the monitor resource assignments that sets up later to be
applied configurations of the mode setting objects, but with the new
hooks into the backend, so that we don't need to teach the monitor
config manager about planes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2398
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
This means that it doesn't necessarily mean what transform / rotation
the hardware resource gets, e.g. it instead represents the logical
transform related to the configured mode. This allows us to postpone
checking the plane capabilities until later (as rotation capabilities
depends is a plane property), when a plane has been assigned.
This was in practice already handled when configuring the
transform-via-offscreen case, handled when creating the view, and the
mode setting configuration.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
When we're configuring monitors, allow backends to add backend specific
assignments during resource assignment (mapping connectors and CRTCs
etc).
This will later allow the native backend's KMS monitor resources to
assign a primary plane and optionally a cursor plane during
configuration. This will then dictate what plane will be used for
primary plane updates, as well as cursor updates, until reconfigured
again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
Musl doesn't seem to include this by default so explicitly including it
should fix compilation on Musl.
Tested with Clang 16/17 and GCC 14.
Error:
src/backends/meta-fd-source.c:70:3: error: call to undeclared function 'close'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
close (fd_source->poll_fd.fd);
^
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3078
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3455>
Otherwise a tablet in relative mode will never have a tool set and
nothing happens on motion events - meta_wayland_tablet_seat_update()
simply exits early for tablet proximity, button or motion events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3410>
This is a step in cleaning up the Clutter context management. By making
it a GObject it's easier to add e.g. properties and features that helps
with introspection.
For now, this means the context creation is changed to go via a
"constructor" (clutter_create_context()). This is so that the global
context singleton can be mantained outsid of ClutterContext, until it
can be removed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2016>
The original purpose of being able to report errors is no longer
relevant, since the Clutter backend is now practically a thin wrapper
around the actual backend, which has already dealt with error reporting.
Thus move this to the regular constructor path.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2016>
Since meta_kms_impl_device_get_sync_file always returns the same
file descriptor referencing the same sync_file, this means the atomic
ioctl doesn't need to wait for any fences to signal. This is fine
because we already waited for the buffer to become idle before applying
the Wayland surface state.
Fixes the atomic commit ioctl spuriously synchronizing to the screen
cast paint (at least with the amdgpu driver), which could result in
the page flip missing its target scanout cycle.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3148
v2:
* Rename local variable to signaled_sync_file for consistency with new
function name
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3389>
It returns a file descriptor which references a signaled sync_file.
v2:
* Change function name and add Doxygen comment to hopefully make its
purpose a bit clearer (Ivan Molodetskikh)
v3: (Jonas Ådahl)
* Create sync_file from scratch via a syncobj, no buffer needed anymore
* Initialize priv->sync_file = 1 and use g_clear_fd in finalize
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3389>
While we should ideally have a sensible cursor theme, handle the
case of cursor themes that lack certain cursor names, and fallback
to the 'default' cursor in those cases.
The 'grey rectangle' fallback is still left, in case we even fail
to load a 'default' cursor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3295>
When a stream is destroyed by a consumer, mutter won't be able to
recognize that.
For mutter, the stream just paused, but did not disconnect, because the
connection state of a PipeWire stream only represents, whether the
respective PipeWire context is connected to PipeWire.
In addition to that, it may be the case, that the stream consumer just
recreates the stream.
So even if mutter would be able to know, when the stream consumer
destroyed a stream, but not the whole screencast or remote-desktop
session, then mutter would not know, whether the stream will be resumed
eventually or not.
So, add an explicit API call to the screencast interface to stop a
stream.
For virtual streams, this also means, that the respective virtual
monitor is destroyed.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2889
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3307>
When a virtual stream is destroyed, its respective virtual monitor is
destroyed too. When the virtual monitor is destroyed, mutter reloads
the monitor manager.
However, at this point, the virtual stream is not completely destroyed
yet. The viewport of the virtual monitor still exists at this point and
when the monitor manager reloads, it will try to fetch the logical
monitor of the now destroyed virtual monitor, which will fail and thus
gnome-shell will run into a segfault.
Fix this situation by reloading the monitor manager in an idle callback.
When the monitor manager reloads, the virtual monitor is completely
gone, since the viewport of the virtual monitor is destroyed after the
virtual monitor itself.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2864
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3307>
There is no way to set any gamma luts, or do anything other color
management related. Eventually we'll probably want to, but that requires
bringing color management plumbing to PipeWire.
Doing this is also needed when running a headless session, as when
headless, polkit doesn't let us create colord devices without explicit
user permission, meaning we'll spam the session with useless dialogs
each time a session is started.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3423>
`count_mode_setting_devices` was incorrect in both name and in function.
What it was actually doing was counting GPUs that had been registered with
the backend so far (during the `init_gpus` loop). What it was intended to
do was to count the number of `MetaRenderDeviceEglStream` instances, which
is the thing we're limited to only one of. So `count_mode_setting_devices`
would return zero whenever the first GPU initialized happened to be a
`MetaRenderDeviceEglStream`, which would in turn prevent
`MetaRenderDeviceEglStream` from successfully initializing. Seems it only
ever worked in the case of a hybrid system where the first GPU initialized
was GBM-based.
Now we count `MetaRenderDeviceEglStream` instances (zero or one) externally.
This allows initialization to succeed when it happens to be the first (or
only) GPU. And so `MUTTER_DEBUG_FORCE_EGL_STREAM=1` now works.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2905>
