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>
This allows to capture the next update of all stage views using
meta_backend_renderdoc_capture. Finer control over what stage view is
captured when can be added in the future.
Currently, renderdoc does not support the GL_OES_EGL_image extension
that we depend on for importing dma-bufs. This means that dma-buf
support is broken when mutter in launched with renderdoc.
One can hack up renderdoc to pretend to support GL_OES_EGL_image and
specifically EGLImageTargetTexture2DOES to restore the full mutter
functionality but renderdoc captures replay with a black rectangle where
those dma-buf buffers are being painted.
See:
https://registry.khronos.org/OpenGL/extensions/OES/OES_EGL_image.txthttps://registry.khronos.org/OpenGL/extensions/OES/OES_EGL_image_external.txt
It looks like the renderdoc maintainer does not want to merge support
for the extension: https://github.com/baldurk/renderdoc/pull/2845
We would only need support for dma-buf EGLImages which so it might be
possible to convince the maintainer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4061>
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>
Overlays are always cursors, and "redraw overlay" doesn't communicate
that. Add "cursor" or "cursor overlay" to some functions to make it a
bit more obvious in a couple of places.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4066>
There were things hooked up (connecting signals, adding stage watches),
but it was a bit disorganized, with "adding watches" doing more, and
"init callbacks" being a bit vague. Split things up to
* setup view - hook up things that need to listen on a stage view
* setup cursor tracking - track cursor positions, sprite changes
* the rest - monitor changes etc
This also properly handles a race condition when we'll enable before the
idle callback creating the view from the virtual monitors is run.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4066>
The hardware cursor support in the cursor renderer now acts on a per
stage view basis, so no need to inhibit the hardware cursor, it isn't
going to try to put a hardware cursor on a virtual CRTC anyway.
Instead use overlay inhibitation to decide whether an cursor overlay
should be painted or not. Inhibit the overlay when hidden/metadata, but
not when embedded.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4066>
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>
The client may not wait for devices to be created before enabling,
meaning we might activate the input capture session before the device
emulation is started. This would result in events silently being
dropped.
This helps with the flaky input-capture test case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4128>
Use the 'seq' field in the spa_meta_header struct to track buffer
sequence numbers. This can be useful for predictable buffer tracking in
consumers, or for debugging purposes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4065>
This will become important when dispatching happens from a frame clock
driver, where the driver itself triggers from a GSource. If the driver
source has a higher priority, we'll risk dispatching before the frame
clock has returned to a state expecting to be dispatched.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4065>
Touch devices are handled very similarly to how absolute pointer
devices, by creating either shared or standalone devices depending on
what kind of monitor it's associated with.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4064>
A EIS client might want to unbind a device capability; doing so should
effectively remove the device, which we didn't. Instead we always
created devices that a seat bind event had capabilities set for.
Fix this by explicitly keeping track of what is our "keyboard", our
"pointer", and whether we have a set of abs pointers, and don't create
duplicates if we already have devices created. For absolute pointer
devices, just keep track if we should have them, because we might have
many, or none, if we happen to be headless at the time being.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4064>
We don't need two separate configuration helpers, they do the same
thing. This will simplify making the viewport dependent device creation
more generic and reusable.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4064>
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>
The other similar API all operate with the assumptions that (0,0) is at
the top left, so lets make damage regions behave this way too. Add a
helper to flip the rectangles, to make it a bit more convenient. It'll
be used in more places in a follow up.
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>
