The DRM buffers aren't really tied to mode setting, so they shouldn't
need to have an associated mode setting device. Now that we have a
device file level object that can fill this role, port over
MetaDrmBuffer and friends away from MetaKmsDevice to MetaDeviceFile.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
It seems to be the preferred format of the Mesa V3D driver on
Raspberry Pi 4. If the compositor doesn't advertise it then Mesa will
fallback from `zwp_linux_dmabuf_v1` to `wl_drm`, incorrectly. Meaning
it will keep using a buffer with modifiers on an interface that does
not have modifiers.
Add support for `DRM_FORMAT_ABGR2101010`. It works, and prevents Mesa
from taking its broken fallback path.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1520
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1798>
This commit consolidates DRM buffer management to the MetaDrmBuffer
types, where the base type handles the common functionality (such as
managing the framebuffer id using drmModeAdd*/RMFb()), and the sub types
their corresponding type specific behavior.
This means that drmModeAdd*/RmFB() handling is moved from meta-gpu-kms.c
to meta-drm-buffer.c; dumb buffer allocation/management from
meta-renderer-native.c.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Just as wl_shm, hook up the Wayland DMA-BUF protocol to the 64 bit half
point pixel formats too. This makes it possible for Wayland EGL clients
to use 64 bit pixel EGL configurations.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/804
A DMA buffer might not be able to scanout, and in that case the import
with GBM_BO_USE_SCANOUT will fail. Handle that by failing to scanout,
effectively falling back to compositing.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1261
This will check whether the current backing buffer is compatible with
the primary plane of the passed CoglOnscreen. Since this will extend the
time before a buffer is released, the MetaWaylandBufferRef is swapped
and orphaned if a new buffer is committed before the previous one was
released. It'll eventually be released, usually by the next page flip
callback.
Currently implemented for EGLImage and DMA-BUF buffer types.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Advertising support for modifiers means we will most likely not not be
able to scan out client buffers directly, meaning it just as likely that
we won't be able to scan out even fullscreen windows without atomic KMS.
When we have atomic support, we should advertise support for modifiers
if atomic is used to drive the CRTCs, as we by then can check whether we
can scan out directly, place in an overlay plane, etc.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
As with most other state that ends up being pushed to the actor and the
associated shaped texture, also push the texture and the corresponding
metadata from the actor surface. This fixes an issue when a toplevel
surface was reset, where before the subsurface content was not properly
re-initialized, as content state synchronization only happened on
commit, not when asked to synchronize.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
It's not always clear how the dma-buf functions work (e.g. where memory
is allocated) without actually going in-depth in the code. This just
adds a few commments to more quickly gain understanding.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/871
Some drivers expose EGL_EXT_image_dma_buf_import_modifiers so you can
query supported formats, but don't support any modifiers. Handle this by
treating it like DRM_FORMAT_MOD_INVALID.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/782
Prior to this commit, MetaWaylandSurface held a reference to
MetaWaylandBuffer, who owned the texture drawn by the surface. When
switching buffer, the texture change with it.
This is problematic when dealing with SHM buffer damage management, as
when having one texture per buffer, damaged regions uploaded to one,
will not follow along to the next one attached. It also wasted GPU
memory as there would be one texture per buffer, instead of one one
texture per surface.
Instead, move the texture ownership to MetaWaylandSurface, and have the
SHM buffer damage management update the surface texture. This ensures
damage is processed properly, and that we won't end up with stale
texture content when doing partial texture uploads. If the same SHM
buffer is attached to multiple surfaces, each surface will get their own
copy, and damage is tracked and uploaded separately.
Non-SHM types of buffers still has their own texture reference, as the
texture is just a representation of the GPU memory associated with the
buffer. When such a buffer is attached to a surface, instead the surface
just gets a reference to that texture, instead of a separately allocated
one.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/199
What was actually done when calling meta_wayland_buffer_attach() was
that the texture was realized, so just call the function
`meta_wayland_dma_buf_realize_texture()` and call that.
This is in preparation to change how meta_wayland_buffer_attach() work.
https://gitlab.gnome.org/GNOME/mutter/issues/199
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
Commit 22723ca37 moved buffer realization to
meta_wayland_surface_commit() so that it wouldn't be part of
meta_wayland_buffer_attach().
However, creation of dmabuf buffers would call into
meta_wayland_buffer_attach() directly without realizing the buffer
first. attach() would then fail and mutter would effectively shut down
any clients using the zwp_linux_dmabuf protocol (note that if such
client was Xwayland, mutter itself would shut down as well).
Add the missing bit in order to make zwp_linux_dmabuf protocol work
again.
The modifier event was only added in v3 of the client; sending it to
older clients (e.g. GStreamer waylandsink) causes them to disconnect
immediately.
Send the older 'format' event to all clients, and only send the newer
'modifier' event to resource versions 3 or above.
https://bugzilla.gnome.org/show_bug.cgi?id=788558
Apparently my understanding of Cogl pixel formats, or at least their
use, was somewhat shaky.
Un-invert the inversion of the DRM FourCC -> Cogl pixel format mapping
when creating dmabufs from clients, fixing inverted channel ordering
seen from GL clients, e.g. gold highlights in gtk4-demo when using the
GSK GL backend when they should be blue.
https://bugzilla.gnome.org/show_bug.cgi?id=786677
