The intention with KMS abstraction is to hide away accessing the drm
functions behind an API that allows us to have different kind of KMS
implementations, including legacy non-atomic and atomic. The intention
is also that the code interacting with the drm device should be able to
be run in a different thread than the main thread. This means that we
need to make sure that all drm*() API usage must only occur from within
tasks that eventually can be run in the dedicated thread.
The idea here is that MetaKms provides a outward facing API other places
of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is
an internal implementation that only gets interacted with via "tasks"
posted via the MetaKms object. These tasks will in the future
potentially be run on the dedicated KMS thread. Initially, we don't
create any new threads.
Likewise, MetaKmsDevice is a outward facing representation of a KMS
device, while MetaKmsImplDevice is the corresponding implementation,
which only runs from within the MetaKmsImpl tasks.
This commit only moves opening and closing the device to this new API,
while leaking the fd outside of the impl enclosure, effectively making
the isolation for drm*() calls pointless. This, however, is necessary to
allow gradual porting of drm interaction, and eventually the file
descriptor in MetaGpuKms will be removed. For now, it's harmless, since
everything still run in the main thread.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
Fix the following compiler warning:
../src/backends/native/meta-renderer-native.c: In function ‘meta_renderer_native_create_view’:
/usr/include/glib-2.0/glib/gmacros.h:523:17: warning: ‘formats’ may be used uninitialized in this function [-Wmaybe-uninitialized]
523 | { if (_ptr) (cleanup) ((ParentName *) _ptr); } \
| ^
../src/backends/native/meta-renderer-native.c:773:22: note: ‘formats’ was declared here
773 | g_autoptr (GArray) formats;
| ^~~~~~~
https://gitlab.gnome.org/GNOME/mutter/merge_requests/632
Make sure to destroy the EGL surface after releasing held buffers,
otherwise we'll get the following valgrind warnings:
==24016== Invalid read of size 8
==24016== at 0x1739943F: release_buffer (platform_drm.c:73)
==24016== by 0x49AC355: meta_drm_buffer_gbm_finalize (meta-drm-buffer-gbm.c:213)
==24016== by 0x4B75B61: g_object_unref (gobject.c:3346)
==24016== by 0x49B4B41: free_current_bo (meta-renderer-native.c:991)
==24016== by 0x49B816F: meta_renderer_native_release_onscreen (meta-renderer-native.c:2971)
==24016== by 0x5209441: _cogl_onscreen_free (cogl-onscreen.c:167)
==24016== by 0x5208D81: _cogl_object_onscreen_indirect_free (cogl-onscreen.c:51)
==24016== by 0x51C8066: _cogl_object_default_unref (cogl-object.c:103)
==24016== by 0x5207989: _cogl_framebuffer_unref (cogl-framebuffer.c:1814)
==24016== by 0x51C80B1: cogl_object_unref (cogl-object.c:115)
==24016== by 0x53673C7: clutter_stage_view_dispose (clutter-stage-view.c:304)
==24016== by 0x4B75AF2: g_object_unref (gobject.c:3309)
==24016== Address 0x18e742a8 is 536 bytes inside a block of size 784 free'd
==24016== at 0x4839A0C: free (vg_replace_malloc.c:540)
==24016== by 0x17399764: dri2_drm_destroy_surface (platform_drm.c:231)
==24016== by 0x1738550A: eglDestroySurface (eglapi.c:1145)
==24016== by 0x5440286: eglDestroySurface (in /home/jonas/Dev/gnome/install/lib/libEGL.so.1.1.0)
==24016== by 0x49613A5: meta_egl_destroy_surface (meta-egl.c:432)
==24016== by 0x49B80F9: meta_renderer_native_release_onscreen (meta-renderer-native.c:2954)
==24016== by 0x5209441: _cogl_onscreen_free (cogl-onscreen.c:167)
==24016== by 0x5208D81: _cogl_object_onscreen_indirect_free (cogl-onscreen.c:51)
==24016== by 0x51C8066: _cogl_object_default_unref (cogl-object.c:103)
==24016== by 0x5207989: _cogl_framebuffer_unref (cogl-framebuffer.c:1814)
==24016== by 0x51C80B1: cogl_object_unref (cogl-object.c:115)
==24016== by 0x53673C7: clutter_stage_view_dispose (clutter-stage-view.c:304)
==24016== Block was alloc'd at
==24016== at 0x483AB1A: calloc (vg_replace_malloc.c:762)
==24016== by 0x173997AE: dri2_drm_create_window_surface (platform_drm.c:145)
==24016== by 0x17388906: _eglCreateWindowSurfaceCommon (eglapi.c:929)
==24016== by 0x5440197: eglCreateWindowSurface (in /home/jonas/Dev/gnome/install/lib/libEGL.so.1.1.0)
==24016== by 0x49612FF: meta_egl_create_window_surface (meta-egl.c:396)
==24016== by 0x49B752E: meta_renderer_native_create_surface_gbm (meta-renderer-native.c:2538)
==24016== by 0x49B7E6C: meta_onscreen_native_allocate (meta-renderer-native.c:2870)
==24016== by 0x49B8BCF: meta_renderer_native_create_view (meta-renderer-native.c:3387)
==24016== by 0x48D274B: meta_renderer_create_view (meta-renderer.c:78)
==24016== by 0x48D27DE: meta_renderer_rebuild_views (meta-renderer.c:111)
==24016== by 0x49BB4FB: meta_stage_native_rebuild_views (meta-stage-native.c:142)
==24016== by 0x49A733C: meta_backend_native_update_screen_size (meta-backend-native.c:517)
https://gitlab.gnome.org/GNOME/mutter/merge_requests/622
When making a new surface/context pair current, mesa may want to flush
the old context. Make sure we don't try to flush any freed memory by
unmaking a surface/context pair current before freeing it.
Not doing this results in the following valgrind warnings:
==15986== Invalid read of size 8
==15986== at 0x69A6D80: dri_flush_front_buffer (gbm_dri.c:92)
==15986== by 0x1750D458: intel_flush_front (brw_context.c:251)
==15986== by 0x1750D4BB: intel_glFlush (brw_context.c:296)
==15986== by 0x1739D8DD: dri2_make_current (egl_dri2.c:1461)
==15986== by 0x17393A3A: eglMakeCurrent (eglapi.c:869)
==15986== by 0x54381FB: InternalMakeCurrentVendor (in /home/jonas/Dev/gnome/install/lib/libEGL.so.1.1.0)
==15986== by 0x5438515: eglMakeCurrent (in /home/jonas/Dev/gnome/install/lib/libEGL.so.1.1.0)
==15986== by 0x522A782: _cogl_winsys_egl_make_current (cogl-winsys-egl.c:303)
==15986== by 0x49B64C8: meta_renderer_native_create_view (meta-renderer-native.c:3076)
==15986== by 0x48D26E7: meta_renderer_create_view (meta-renderer.c:78)
==15986== by 0x48D277A: meta_renderer_rebuild_views (meta-renderer.c:111)
==15986== by 0x49BF46E: meta_stage_native_rebuild_views (meta-stage-native.c:142)
==15986== Address 0x1b076600 is 0 bytes inside a block of size 48 free'd
==15986== at 0x4839A0C: free (vg_replace_malloc.c:540)
==15986== by 0x49B59F3: meta_renderer_native_release_onscreen (meta-renderer-native.c:2651)
==15986== by 0x5211441: _cogl_onscreen_free (cogl-onscreen.c:167)
==15986== by 0x5210D81: _cogl_object_onscreen_indirect_free (cogl-onscreen.c:51)
==15986== by 0x51D0066: _cogl_object_default_unref (cogl-object.c:103)
==15986== by 0x520F989: _cogl_framebuffer_unref (cogl-framebuffer.c:1814)
==15986== by 0x51D00B1: cogl_object_unref (cogl-object.c:115)
==15986== by 0x536F3C7: clutter_stage_view_dispose (clutter-stage-view.c:304)
==15986== by 0x4B7DAF2: g_object_unref (gobject.c:3309)
==15986== by 0x4A9596C: g_list_foreach (glist.c:1013)
==15986== by 0x4A9599A: g_list_free_full (glist.c:223)
==15986== by 0x48D2737: meta_renderer_rebuild_views (meta-renderer.c:100)
==15986== Block was alloc'd at
==15986== at 0x483AB1A: calloc (vg_replace_malloc.c:762)
==15986== by 0x69A76B2: gbm_dri_surface_create (gbm_dri.c:1252)
==15986== by 0x69A6BFE: gbm_surface_create (gbm.c:600)
==15986== by 0x49B4E29: meta_renderer_native_create_surface_gbm (meta-renderer-native.c:2221)
==15986== by 0x49B57DB: meta_onscreen_native_allocate (meta-renderer-native.c:2569)
==15986== by 0x49B6423: meta_renderer_native_create_view (meta-renderer-native.c:3062)
==15986== by 0x48D26E7: meta_renderer_create_view (meta-renderer.c:78)
==15986== by 0x48D277A: meta_renderer_rebuild_views (meta-renderer.c:111)
==15986== by 0x49BF46E: meta_stage_native_rebuild_views (meta-stage-native.c:142)
==15986== by 0x49A75B5: meta_backend_native_update_screen_size (meta-backend-native.c:520)
==15986== by 0x48B01BB: meta_backend_sync_screen_size (meta-backend.c:224)
==15986== by 0x48B09B7: meta_backend_real_post_init (meta-backend.c:501)
https://gitlab.gnome.org/GNOME/mutter/merge_requests/622
Currently the EGLDevice code gets the display and calls eglInitialize.
As a follow-up it checks the required EGL extensions - technically it
could check the EGL device extensions earlier.
In either case, eglTerminate is missing. Thus the connection to the
display was still bound.
This was highlighted with Mesa commit d6edccee8da ("egl: add
EGL_platform_device support") + amdgpu.
In that case, since the eglTerminate is missing, we end up reusing the
underlying amdgpu_device due to some caching in libdrm_amdgpu. The
latter in itself being a good solution since it allows buffer sharing
across primary and render node of the same device.
Note: we should really get this in branches all the way back to 3.30.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/619
Fixes: 934184e23 ("MetaRendererNative: Add EGLDevice based rendering support")
Cc: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Extract the next buffer -logic into a new function. This allows to
simplify copy_shared_framebuffer_cpu () making it more readable.
This change is a pure refactoring, no functional changes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/593
There is no reason why we should have an internal type enum when we have
all the infrastructure to just use multiple GObject types. Also there
was no code sharing between the old "types", the only common API was
getting the framebuffer ID, so lets make that a vfunc.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/584
Since "renderer/native: make EGL initialization failure not fatal" it is
possible, under specific failure conditions, to end up with a primary GPU whose
EGL initialization failed. That cannot work.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/521
The failure to initialize EGL does not necessarily mean the KMS device cannot
be used. The device could still be used as a "secondary GPU" with the CPU copy
mode.
If meta_renderer_native_create_renderer_gpu_data () fails,
meta_renderer_native_get_gpu_data () will return NULL, which may cause crashes.
This patch removes most of the failures, but does not fix the NULL dereferences
that will still happen if creating gpu data fails.
This patch reorders create_renderer_gpu_data_gbm () so that it fails hard only
if GBM device cannot be created, and otherwise always returns an initialized
gpu data structure. Users of the gpu data structure are responsible for
checking egl_display validity.
The GBM device creation failure is a hard failure because presumably GBM is
necessary for cursors.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/542https://gitlab.gnome.org/GNOME/mutter/merge_requests/521
We're currently always waiting for unfinished page flips before flipping
again. This is awkward when we are in an asynchronous retry-page-flip
loop, as we can synchronously wait for any KMS page flip event.
To avoid ending up with such situations, just freeze the frame clock
while we're retrying, then thaw it when we succeded.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
We rely on the frame clock to compress input events, thus if the frame
clock stops, input events are not dispatched. At the same time, there
is no reason to redraw at a full frame rate, as nothing will be
presented anyway, so slow down to 10Hz (compared to the most common
60Hz). Note that we'll only actually reach 10Hz if there is an active
animation being displayed, which won't happen e.g. if there is a screen
shield in the way.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
When we're in a page-flip retry loop due to the FIFO being full
(drmModePageFlip() failing with EBUSY), we should not continue to try
when starting to power save, as that means we're blocking new frames,
which itself blocks input events due to them being compressed using the
frame clock.
We'd also hit an assert assuming we only try to page flip when not power
saving.
Thus, fake we flipped if we ended up reaching a power saving state while
retrying.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/509https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
It tried to add a (implicitly casted) float to a uint64_t, and due to
floating point precision issues resulted in timestamps intended to be
in the future to actually be in the past. Fix this by first casting the
delay to an uint64_t, then add it to the time stamp.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
DPMS is configured from a bit all over the place: via D-Bus, via X11 and
when reading the current KMS state. Each of these places did it slightly
differently, directly poking at the field in MetaMonitorManager.
To make things a bit more managable, move the field into a new
MetaMonitorManagerPrivate, and add helpers to get and set the current
value. Prior to this, there were for example situations where the DPMS
setting was changed, but without signal listeners being notified about
it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
The 'underscan' property is a drm connector property, not a CRTC
property, so we would never find it. We also didn't advertise support
for the feature, meaning even if it was on the CRTC, Settings wouldn't
know about it.
Fix this by moving the property to where it belongs: in MetaOutputKms,
and properly advertise support for it if the property is found.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/507
A clutter actor might be painted on a stage view with a view scale
other than 1. In this case, to show the content in full resolution, the
actor must use a higher resolution resource (e.g. texture), which will
be down scaled to the stage coordinate space, then scaled up again to
the stage view framebuffer scale.
Use a 'resource-scale' property to save information and notify when it
changes.
The resource scale is the ceiled value of the highest stage view scale a
actor is visible on. The value is ceiled because using a higher
resolution resource consistently results in better output quality. One
reason for this is that rendering is often not perfectly pixel aligned,
meaning even if we load a resource with a suitable size, due to us still
scaling ever so slightly, the quality is affected. Using a higher
resolution resource avoids this problem.
For situations inside clutter where the actual maximum view scale is
needed, a function _clutter_actor_get_real_resource_scale() is provided,
which returns the non-ceiled value.
Make sure we ignore resource scale computation requests during size
requests or allocation while ensure we've proper resource-scale on
pre-paint.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
We might fail to page flip a new buffer, often after resuming, due to
the FIFO being full. Prior to this commit, we handled this by switching
over to plain mode setting instead of page flipping. This is bad because
we won't be synchronized to the refresh rate anymore, but just the
clock.
Instead, deal with this by trying again until the FIFO is no longer
full. Do this on a v-sync based interval, until it works.
This also changes the error handling code for drivers not supporting
page flipping to rely on them returning -EINVAL. The handling is moved
from pretending a page flip working to explicit mode setting in
meta-renderer-native.c.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/460
A renderer view will, under the native backend, since long ago always
have a logical monitor associated with it, so remove the code handling
the legacy non-stage view case.
https://gitlab.gnome.org/GNOME/mutter/issues/460
When we freed the cursor GPU state including the gbm_bo objects attached
to it, we didn't unset the cursor renderer private of the CRTCs of the
associated GPU. This means that HW cursor invalidation could potentially
break if a new gbm_bo happened to be allocated at the same memory
address as the previous one.
To avoid this, iterate through the CRTCs of the GPU of which the cursor
data is freed, and unset the cursor renderer private if it was the one
destroyed.
https://gitlab.gnome.org/GNOME/mutter/issues/199
This means we need to make sure we don't accidentally free the provided
source GError (which automatically happens with `g_autoptr`), so use
`g_steal_pointer()`.
This fixes an issue where, when launched in a bubblewrap environment
(such as the one provided by Buildstream), mutter would give the
following warning message:
```
mutter-WARNING **: 8:31:35:069: Can't initialize KMS backend: (null)
```
... which isn't that useful when trying to debug the actual issue.
If the extension is missing, the GPU copy path would not work. The code sets
the error, but forgets to return a failure. Fix this.
While adding the necessary return FALSE, also destroy the EGL context we just
created. Code refactoring shares the destroying code.
Found by reading code.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/416
If the GPU copy path would use a software renderer, fall back to the CPU
copy path. The CPU copy path is possibly faster and avoids screen
corruption issues that were observed on an Intel Haswell desktop. The
corruption was likely due to texturing from an unfinished rendering or
memory caching issues.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/325
Print the pixel format chosen for an output on a secondary GPU for
debugging. Knowing the format can aid in debugging e.g. red/blue channel
swaps and CPU copy performance issues.
This adds a DRM format printing helper in meta-crtc-kms.h. This header
is included in most native backend files making it widely available,
while DRM formats are specific to the native backend. It could be shared
with Wayland bits, DRM format codes are used there too.
The helper makes the pixel format much more readable than a "%x".
https://gitlab.gnome.org/GNOME/mutter/merge_requests/341
When setting up an output on a secondary GPU with the CPU copy mode,
allocate the dumb buffers with a DRM format that is advertised supported
instead of hardcoding a format.
Particularly, DisplayLink devices do not quite yet support the hardcoded
DRM_FORMAT_XBGR8888. The proprietary driver stack actually ignores the
format assuming it is DRM_FORMAT_XRGB8888 which results the display
having red and blue channels swapped. This patch fixes the color swap
right now, while taking advantage if the driver adds support for XBGR
later.
The preferred_formats ordering is somewhat arbitrary. Here it is written
from glReadPixels point of view, based on my benchmarks on Intel Haswell
Desktop machine. This ordering prefers the format that was hardcoded
before.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/341
These functions allow inspecting which pixel formats a CRTC's primary
plane supports. Future patches will inspect the supported formats and
pick a framebuffer format accordingly instead of hardcoding a format.
The copy list function will be used to initialize a formats list, and
the supports format function will be used to intersect that list against
another CRTC's supported formats.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/341
