This makes DMA buffer allocation in all layers take an array of possible
modifiers to allocate using, or zero modifiers if implicit modifiers
should be used.
The format hard coding previously used is moved to the screen cast code,
or in case of the (unused by default) shadow buffer buffers use the same
format as the the CoglOnscreen.
This also means the CoglDmaBufHandle and MetaDrmBuffer got taught how to
distinguish between planes. It's mostly unused in practice, so rather
untested.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3900>
It's only implemented by the GBM render device backend, and uses EGL,
thus does not distinguish scanout capable modifiers.
A filter enum is added to Cogl, since it'll be used via the Cogl API,
but the actual Cogl API isn't added yet.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3900>
On big endian machine, the native 32bits format is
DRM_FORMAT_BGRX8888, so add this format to the list.
Tested on a s390x VM, using virtio-gpu driver.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4088>
In add_drm_device, calling g_hash_table_insert with NULL for the hash
table (which happens for any device added after mutter finished starting
up) would presumably just drop the key/value pointers on the floor,
leaking the string & MetaRenderDevice object referenced by them. Fixing
this should help for the referenced issue.
In meta_backend_native_take_render_device, g_hash_table_steal_extended
would presumably return FALSE (and log a warning), so the behaviour would
be "correct" by chance.
Issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/3785
Fixes: 58c3734d78e9 ("backend/native: Prepare render devices earlier than KMS")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4136>
In contrast to realtime scheduling, this doesn't risk us getting
SIGKILL:ed when the kernel is doing busy looping in
drmModeAtomicCommit() for some reason, but will according to testing,
right now, give us more or less the same benefit when it comes to
dispatch lateness and commit lateness.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4124>
Either prefer "normal" or "realtime", via an enum, instead of a boolean.
Also make it configurable with an env var
`MUTTER_DEBUG_KMS_SCHEDULING_PRIORITY`, which can be set to either
`normal` or `realtime`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4124>
Some laptops don't have the integrated GPU come earlier in the PCI topology
which means that when mutter enumerates the GPUs it may select the dGPU
as the primary.
In a laptop context, this is unlikely to work because the eDP panel can
only be actively connected to a single GPU at a time.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3746
Suggested-by: Jonas Ådahl
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4114>
For some reason the variable for the *Native subclass of
MetaVirtualInputDevice was suffixed with _evdev. Long long ago the input
backend in clutter was called "evdev", so might be because of that.
Anyway, lets rename to something more closely related, i.e. _native.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4064>
The underlying data structure of MtkRegion is pixman_region32, which
gives us boxes, not rectangles. Use the new get_box() API to bypass
going via rectangles to get the boxes directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4103>
Go one step further and pass regions. Sometimes the rectangles were
already a region, e.g. the swap-buffer case, and sometimes it still
potentially needs to pass through a rectangle array, e.g. damage with a
view transform.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4103>
Only before passing to EGL does it need to become a int tuple array.
It's used in non-EGL places which now become more easy to read. While at
it, make use of the new (and tweaked) helper function for flipping
rectangles from "cogl space" to "GL space".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4103>
Now that connectors can be configured as for lease, rename the function
to meta_kms_connector_is_non_desktop() to make clear that it returns
the hardware configuration rather than the user configuration.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4112>
Add a flag to MetaMonitor indicating if the monitor is available for
lease and store/update it from the monitor configuration.
Also, add unit tests validating that the configuration is applied and
that invalid configurations fail.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4112>
cogl_framebuffer_finish can result in a CPU-side stall because it waits for
the primary GPU to flush and execute all commands that were queued before
that. By using a GPU-side EGLSync we can let the primary GPU inform us when
it is done with the queued commands instead. We then create another EGLSync
on the secondary GPU using the same fd so the primary GPU effectively
signals the secondary GPU when it is done rendering, causing the latter
to wait for the former before copying part of the frames it needs for
monitors attached to it directly.
This solves the corruption that cogl_framebuffer_finish also solved, but
without needing a CPU-side stall.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4015>
The sync_fd represents only the primary GPU work.
Fixes: c2621eca151d ("onscreen/native: Set latest cogl sync_fd on KMS update")
v2:
* Use g_steal_fd. (Georges Basile Stavracas Neto, Sebastian Wick)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4060>
Previously ClutterStageWindow was an interface with only one base
implementation (MetaStageImpl) which others inherit from.
This just makes it a class so that we can use _GET_CLASS() API instead of
the costly (by comparison) _GET_IFACE() vtable lookups.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4048>
In some use cases there is a need to dynamically change the preferred
primary GPU, or get rid of the preference altogether. This is currently
not possible due to a change in udev introduced by systemd v247. This
version made the tags "sticky", meaning there is no way to remove them
once attached. When a tag gets removed, only the CURRENT_TAGS property
reflects that change, the removed tag will remain in the TAGS property.
This also bumps libgudev version to 238, since that version introduces
a function, which we need to get the current tags.
Related: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4055>
drmModeAddFB() doesn't take a format, but depth and bits per pixel.
These can be used to determine whether there should be an alpha channel
or not, and is roughly assumed to result in either XR24 or AR24 if one
passes 24 or 32 as depth, with 32 as bpp.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3926>
In multi-GPU setups, when one of the GPUs is used to render the desktop
and the other one has all of their devices available for lease,
meta_kms_impl_device_list_lessees() can be called after the device fd
has been unhold.
Make sure to hold and unhold it in this function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4030>
lease_disappeared() was calling meta_drm_lease_disappeared() and
set_connectors_as_available().
meta_drm_lease_disappeared() emits the "revoked" signal, connected to
on_lease_revoked(), which marks the leased connectors as available by
calling set_connectors_as_available().
Therefore, calling set_connectors_as_available() again from
lease_disappeared() is redundant.
Remove the redundant call to set_connectors_as_available() and drop two
unused functions.
Fixes: fc44437876ee ("wayland/drm-lease: Withdrawn leased connectors")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3675
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4029>
We only need to wake up the other side of the GAsyncQueue if we transition
from 0 to 1 item in the queue. Otherwise, we can be certain that the other
side has received a wakeup and will eventually flush the queue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4007>
Preparation for next commit, which may merge multiple KMS updates with
sync_fds for modesets. Waiting for all sync_fds to signal before
processing the merged KMS update would be rather involved, for now just
leave implicit sync enabled for it. We're still relying on implicit sync
for modesets in general anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3999>
g_array_sized_new() creates a new GArray with a preallocated size, but,
after creation, the array length is still zero [1].
Store the modifiers in a EGLuint64KHR array and use g_array_new_take()
to create a new GArray with the correct size.
Because no modifiers were returned, gbm_surface_create() was used
instead gbm_surface_create_with_modifiers() on multi-GPU setups.
[1] https://docs.gtk.org/glib/type_func.Array.sized_new.html
Fixes: aec85281ba ("native/renderer: Retrieve the right modifiers set for each GPU")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3998>
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>
