It was for a failed expriment that tried to mmap() dmabuf memory and
find damaged regions to decrease the amount that was eventually used to
write to an onscreen, but mmap:ing is only fast enough on intel, and
it's only relevant on various server GPUs. For it to be achievable, we
need to render to system memory in a way that we don't need to copy it
out of OpenGL, but that's currently not possible.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3443>
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>
The intention for ClutterContext is to be more or less the MetaContext
or CoglContext equivalent. Lets rename the type so that it becomes more
consistent with the other similar types.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2016>
The current usage of MetaWindow::unmanaging may result in confused
focus window lookups while undoing the MetaWindowDrag grab (i.e.
still pointing to the window that is now being unmanaged).
The meta_window_unmanage() function itself takes care of changing
focus outside of the window being unmanaged, so postpone the
MetaWindowDrag undoing to a point after that is done.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3073
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3376>
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>
Using sized internal formats is required to make sure we actually get
the precision that we want.
The formats should also be renderable, otherwise they can not be used as
a framebuffer attachment. For GLES we have to check for a bunch of
extensions and fall back to internal formats with more bits when they
are not available.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3429>
In GLES 2.0 the required color-renderable formats to support to not
include 8bpc RGB/RGBA formats. The extension adds this requirement and
makes GLES 2.0 actually useable. Not specifying a gl internal format in
Cogl so far has hidden the problem and let the implementation fall back
to RGB585 for example.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3429>
Also be more strict about what we consider RGBA1010102 support. Before
GLES 3.0, using ReadPixels on a framebuffers with format RGB10_A2 was
not possible with type GL_UNSIGNED_INT_2_10_10_10_REV_EXT and thus our
code to read back pixels could fail.
Users of cogl should check those feature flags before using FP16 and
RGBA1010102 pixel formats via CoglFeatureIDs:
* COGL_FEATURE_ID_TEXTURE_RGBA1010102
* COGL_FEATURE_ID_TEXTURE_HALF_FLOAT
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3429>
We might pick an actor that needs relayout. I've seen this happen inside
hiding / unmapping in particular. In this case, calculate_clear_area ()
will call clutter_actor_get_abs_allocation_vertices () which in turn
will force a relayout. However, this is not what we want, because:
1. We don't want to run layout during picking.
2. If the actor needs an allocation, then the pick stack could not have
used an up-to-date allocation, because it is not computed. Therefore
this clear area would use a potentially completely different
allocation than the one stored in the pick stack.
Thankfully, clear area seems to be used as a cache/optimization, so
let's just avoid computing it if the actor is not allocated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3425>
The debug controller can optionally, when passing --debug-control,
enable manipulating debug state, so far enabling/disabling HDR, via
D-Bus.
It's always created, in order to have a place to store debug state and
emit signals etc when it changes, but so far, it doesn't have its own
state it tracks, it just mirrors that of the monitor manager.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3432>
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>
Given destruction order, the display goes away before the stage, so
this lingering signal connection may trigger unintended crashes.
Fixes: 05eeb684d1 ("window: Postpone focusing until grab ended if uninteractable")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3422>
`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>
