The end goal is to have all clutter backend code in src/backends. Input
is the larger chunk of it, which is now part of our specific
MutterClutterBackendX11, this extends to device manager, input devices,
tools and keymap.
This was supposed to be nice and incremental, but there's no sane way
to cut this through. As a result of the refactor, a number of private
Clutter functions are now exported for external backends to be possible.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
Introduce MetaCompositorX11, dealing with being a X11 compositor, and
MetaCompositorServer, being a compositor while also being the display
server itself, e.g. a Wayland display server.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
Add meta-kms and meta-monitor-manager-kms listener for the udev
device-removed signal and on this signal update the device state /
re-enumerate the monitors, so that the monitors properly get updated
to disconnected state on GPU removal.
We really should also have meta-backend-native remove the GPU itself
from our list of GPU objects. But that is more involved, see:
https://gitlab.gnome.org/GNOME/mutter/issues/710
This commit at least gets us to a point where we properly update the
list of monitors when a GPU gets unplugged; and where we no longer
crash the first time the user changes the monitor configuration after
a GPU was unplugged.
Specifically before this commit we would hit the first g_error () in
meta_renderer_native_create_view () as soon as some monitor
(re)configuration is done after a GPU was unplugged.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/713
drmModeGetConnector may fail and return NULL, this may happen when
a connector is removed underneath us (which can happen with e.g.
DP MST or GPU hot unplug).
Deal with this by skipping the connector when enumerating and by
assuming it is disconnected when checking its connection state.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/713
drmModeGetCrtc may fail and return NULL. This will trigger when
meta_kms_crtc_update_state gets called from meta_kms_update_states_sync
after a GPU has been unplugged leading to a NULL pointer deref causing
a crash.
This commit fixes this by checking for NULL and clearing the current_state
when NULL is returned.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/713
Before this commit meta_kms_crtc_read_state was overwriting the
entire MetaKmsCrtcState struct stored in crtc->current_state including
the gamma (sub)struct.
This effectively zero-s the gamma struct each time before calling
read_gamma_state, setting the pointers where the previous gamma values
were stored to NULL without freeing the memory. Luckily this zero-ing
also sets gamma.size to 0, causing read_gamma_state to re-alloc the
arrays on each meta_kms_crtc_update_state call. But this does mean that
were leaking the old gamma arrays on each meta_kms_crtc_update_state call.
This commit fixes this by making meta_kms_crtc_read_state only overwrite
the other values in the MetaKmsCrtcState struct and leaving the gamma
sub-struct alone, this will make read_gamma_state correctly re-use the
gamma tables if the gamma table size is unchanged; or re-alloc them
(freeing the old ones) if the size has changed, fixing the memory leak.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/713
The "device-added" signal should use g_cclosure_marshal_VOID__OBJECT not
g_cclosure_marshal_VOID__VOID.
Instead of fixing this manually, simply replace the closure function for
both signals with NULL, glib will then automatically set the correct
va_marshaller.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/713
Explicitly checking the dimensions of a mode to determine whether it
should be advertised or not fails for portrait style modes. Avoid this
by checking the area instead.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/722
Similar to gtk commit f507a790, this ensures that the valist variant of
the marshaller is used. From that commit's message:
```
If we set c_marshaller manually, then g_signal_newv() will not setup a
va_marshaller for us. However, if we provide c_marshaller as NULL, it will
setup both the c_marshaller (to g_cclosure_marshal_VOID__VOID) and
va_marshaller (to g_cclosure_marshal_VOID__VOIDv) for us.
```
https://gitlab.gnome.org/GNOME/mutter/merge_requests/697
By putting `NULL` as the C marshaller in `g_signal_new`, you
automatically get `g_cclosure_marshaller_generic`, which will try to
process its arguments and return value with the help of libffi and
GValue.
Using `glib-genmarshal` and valist_marshallers, we can prevent this so
that we need less instructions for each signal emission.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/697
This is important when using a touchscreen or stylus instead of a mouse
or touchpad. If the cursor only gets hidden and the focus stays the
same, the window will still send hover events to the UI element under
the cursor causing unexpected distractions while interacting with the
touchscreen.
Fix this by emitting a visibility-changed signal from the cursor tracker
which then triggers a focus surface sync and always set the focus
surface to NULL when it's synced while the cursor is hidden.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/448
Allow checking whether the pointer is visible without accessing the
trackers internal is_showing property. While we don't need this just yet
for reading the visibility inside meta-wayland-pointer, it's useful when
implementing the logic to remove Clutter's focus when the cursor goes
hidden later.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/448
COPY_MODE_PRIMARY has two paths, automatically chosen. For debugging purposes,
e.g. why is my DisplayLink screen slowing down the whole desktop, it will be
useful to know which copy path is taken. Debug prints are added to both when
the primary GPU copy succeeds the first time and when it fails the first time.
This is not the full truth, because theoretically the success/failure could
change every frame, but we don't want to spam the logs (even in debug mode)
every frame. In practise, it should be rare for the success or failure to ever
change. Hence, saying what happened on the first time is enough. This does
indicate if it ever changes even once, too, so we know if that unexpected thing
happens.
The debug prints are per secondary GPU since there could be several.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/615
When the preferred path META_SHARED_FRAMEBUFFER_COPY_MODE_SECONDARY_GPU cannot
be used, as is the case for e.g. DisplayLink devices which do not actually have
a GPU, try to use the primary GPU for the copying before falling back to
read-pixels which is a CPU copy.
When the primary GPU copy works, it should be a significant performance win
over the CPU copy by avoiding stalling libmutter for the duration.
This also renames META_SHARED_FRAMEBUFFER_COPY_MODE_* because the new names are
more accurate. While the secondary GPU copy is always a GPU copy, the primary
copy might be either a CPU or a GPU copy.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/615
This bit of code was more or less duplicated in meta-renderer-native-gles3.c
and meta-wayland-dma-buf.c. Start consolidating the two implementations by
moving the *-gles3.c function into meta-egl.c and generalizing it so it could
also accommodate the meta-wayland-dma-buf.c usage.
The workaround in the *-gles3.c implementation is moved to the caller. It is
the caller's responsibility to check for the existence of the appropriate EGL
extensions.
Commit 6f59e4858e worked around the lack of
EGL_EXT_image_dma_buf_import_modifiers with the assumption that if the modifier
is linear, there is no need to pass it into EGL. The problem is that not
passing a modifier explicitly to EGL invokes implementation-defined behaviour,
so we should not have that workaround in meta-egl.c.
This patch intends to be pure refactoring, no behavioral changes. The one
change is the addition of g_assert to catch overwriting arbitrary memory.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/615
Since 4cae9b5b11, and indirectly before that as well, the
MetaMonitorManager::power-save-mode-changed is emitted even
when the power save mode didn't actually change.
On Wayland, this causes a mode set and therefore a stuttering.
It became more proeminent with the transactional KMS code.
Only emit 'power-save-mode-changed' when the power save mode
actually changed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/674
We need to set XdndAware and XdndProxy on the stage window if running
a X11 compositor, this is not necessary on wayland.
Takes over gnome-shell code doing this initialization.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/667
We currently don't handle the lack of DRM_CLIENT_CAP_UNIVERSAL_PLANES
KMS capability. Fail constructing a device that can't handle this up
front, so later made assumptions, such as presence of a primary plane,
are actually valid.
If we want to support lack of said capability, the required planes need
to be emulated by a dummy MetaKmsPlane object.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/665
There were fallbacks in place in case IN_FORMATS didn't yield any usable
formats: the formats in the drmModePlane struct, and a hard coded array.
The lack of these fallbacks in place could result in a segfault as code
using the supported plane formats assumed there were at least something
in there.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/662
The display name is being used by the monitor manager to expose to name
to the DBUS API.
It is being rebuilt each time, so instead build the displa yname once
for the monitor and keep it around, with an API to retrieve it, so that
we can reuse it in preparation of xdg-output v2 support.
https://gitlab.gnome.org/GNOME/mutter/issues/645
Simplify the call site a bit and make the native renderer know it should
queue mode reset itself when views have been rebuilt. This is done
partly due to more things needing to be dealt with after views have been
rebuilt.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/630
When building without EGL device support, the following compiler warning
is seen:
```
src/backends/native/meta-renderer-native.c:2637:20: warning: unused
variable ‘cogl_renderer_egl’ [-Wunused-variable]
```
Fix the warning by placing the relevant variable declarations within the
`#ifdef HAVE_EGL_DEVICE/#endif` statement.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/656
We used to have wayland-specific paths for this in src/wayland, now we
have ClutterKeymap that we can rely on in order to do state tracking,
and can do this all on src/backend domain.
This accomodates the feature in common code, so will work on both
Wayland and X11.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/590
This commit introduces, and makes use of, a transactional API used for
setting up KMS state, later to be applied, potentially atomically. From
an API point of view, so is always the case, but in the current
implementation, it still uses legacy drmMode* API to apply the state
non-atomically.
The API consists of various buliding blocks:
* MetaKmsUpdate - a set of configuration changes, the higher level
handle for handing over configuration to the impl backend. It's used to
set mode, assign framebuffers to planes, queue page flips and set
connector properties.
* MetaKmsPlaneAssignment - the assignment of a framebuffer to a plane.
Currently used to map a framebuffer to the primary plane of a CRTC. In
the legacy KMS implementation, the plane assignment is used to derive
the framebuffer used for mode setting and page flipping.
This also means various high level changes:
State, excluding configuring the cursor plane and creating/destroying
DRM framebuffer handles, are applied in the end of a clutter frame, in
one go. From an API point of view, this is done atomically, but as
mentioned, only the non-atomic implementation exists so far.
From MetaRendererNative's point of view, a page flip now initially
always succeeds; the handling of EBUSY errors are done asynchronously in
the MetaKmsImpl backend (still by retrying at refresh rate, but
postponing flip callbacks instead of manipulating the frame clock).
Handling of falling back to mode setting instead of page flipping is
notified after the fact by a more precise page flip feedback API.
EGLStream based page flipping relies on the impl backend not being
atomic, as the page flipping is done in the EGLStream backend (e.g.
nvidia driver). It uses a 'custom' page flip queueing method, keeping
the EGLStream logic inside meta-renderer-native.c.
Page flip handling is moved to meta-kms-impl-device.c from
meta-gpu-kms.c. It goes via an extra idle callback before reaching
meta-renderer-native.c to make sure callbacks are invoked outside of the
impl context.
While dummy power save page flipping is kept in meta-renderer-native.c, the
EBUSY handling is moved to meta-kms-impl-simple.c. Instead of freezing the
frame clock, actual page flip callbacks are postponed until all EBUSY retries
have either succeeded or failed due to some other error than EBUSY. This
effectively inhibits new frames to be drawn, meaning we won't stall waiting on
the file descriptor for pending page flips.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
The MetaKmsImpl implementation may need to add a GSource that should be
invoked in the right context; e.g. a idle callback, timeout etc. It
cannot just add it itself, since it's the responsibility of MetaKms to
determine what is the impl context and what is the main context, so add
API to MetaKms to ensure the callback is invoked correctly.
It's the responsibility of the caller to eventually remove and destroy
the GSource.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
As with CRTC state, variable connector state is now fetched via the
MetaKmsConnector. The existance of a connector state is equivalent of
the connector being connected. MetaOutputKms is changed to fetch
variable connector state via MetaKmsConnector intsead of KMS directly.
The drmModeConnector is still used for constructing the MetaOutputKms to
find properties used for applying configuration.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
Move reading state into a struct for MetaCrtcKms to use instead of
querying KMS itself. The state is fetched in the impl context, but
consists of only simple data types, so is made accessible publicly. As
of this, MetaCrtcKms construction does not involve any manual KMS
interaction outside of the MetaKms abstraction.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
Represents drmModeConnector; both connected and disconnected. Currently
only provides non-changing meta data. MetaOutputKms is changed to use
MetaKmsConnector to get basic metadata, but variable metadata, those
changing depending on what is connected (e.g. physical dimension, EDID,
etc), are still manually retrieved by MetaOutputKms.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
A plane is one of three possible: primary, overlay and cursor. Each
plane can have various properties, such as possible rotations, formats
etc. Each plane can also be used with a set of CRTCs.
A primary plane is the "backdrop" of a CRTC, i.e. the primary output for
the composited frame that covers the whole CRTC. In general, mutter
composites to a stage view frame onto a framebuffer that is then put on
the primary plane.
An overlay plane is a rectangular area that can be displayed on top of
the primary plane. Eventually it will be used to place non-fullscreen
surfaces, potentially avoiding stage redraws.
A cursor plane is a plane placed on top of all the other planes, usually
used to put the mouse cursor sprite.
Initially, we only fetch the rotation properties, and we so far
blacklist all rotations except ones that ends up with the same
dimensions as with no rotations. This is because non-180° rotations
doesn't work yet due to incorrect buffer modifiers. To make it possible
to use non-180° rotations, changes necessary include among other things
finding compatible modifiers using atomic modesetting. Until then,
simply blacklist the ones we know doesn't work.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
Add MetaKmsCrtc to represent a CRTC on the associated device. Change
MetaCrtcKms to use the ones discovered by the KMS abstraction. It still
reads the resources handed over by MetaGpuKms, but eventually it will
use only MetaKmsCrtc.
MetaKmsCrtc is a type of object that is usable both from an impl task
and from outside. All the API exposed via the non-private header is
expected to be accessible from outside of the meta-kms namespace.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
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
MetaStageWatch, watch modes and the watch function are part
of the new stage view watching API. It's design does not
rely on signals on purpose; the number of signals that would
be emitted would be too high, and would impact performance.
MetaStageWatch is an opaque structure outside of MetaStage.
This will be used by the screencast code to monitor a single
view, which has a one-to-one relatioship to logical monitors.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/623
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>
When stage views are scaled with fractional scales, the cursor rectangle
won't be aligned with the physical pixel grid, making it potentially
blurry when positioned in between physical pixels. This can be avoided
by aligning the drawn rectangle to the physical pixel grid of the stage
view the cursor is located on.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/413https://gitlab.gnome.org/GNOME/mutter/merge_requests/610
Naming the keyboard accessibility settings `a11y_settings` wrongly
assumes there will never be any other type of accessibility settings.
Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future
confusion.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
MetaProfiler is not built when -Dprofiler=false, and that
breaks the build since MetaBackend unconditionally imports
and uses it.
Fix that by wrapping MetaProfiler in compile-time checks.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/603
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
XkbNewKeyboardNotify informs the client that there is a new keyboard
driving the VCK. It is essentially meant to notify that the keyboard
possibly has a different range of HW keycodes and/or a different
geometry.
But the translation of those keycodes remain the same, and we don't
do range checks or geometry checks (beyond using KEY_GRAVE as "key
under Esc", but that is hardly one). It seems we can avoid the
busywork that is releasing all our passive grabs, reloading the keymap
and regenerating the keycombos and restoring the passive grabs.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/398
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
This is 1) relatively likely as not all touchscreens are nice enough to
report a device size that will help us here and 2) Better than nothing if
everything fails anyway, as it will break on multi-monitor and non-default
monitor rotations.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/581
If we update the ready time while the source is already in the
to-dispatch list, changing the ready time doesn't have any effect, and
the source will still be dispatched. This could cause incorrect idle
watch firing causing the power management plugin in
gnome-settings-daemon to sometimes turn off monitors due to it believing
the user had been idle for some time, while in fact, they just logged
back in.
Fix this by not actually dispatching the idle timeout if the ready time
is in the future when actually dispatching.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/543
Make sure our keyboard accessibility settings structure is all zero
initialized, to avoid potential padding issues on some platform when
comparing settings.
Reported by Daniel van Vugt on IRC.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/552
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
Use the ID_INPUT_WIDTH_MM/ID_INPUT_HEIGHT_MM udev properties to figure out
absolute input devices' physical size. This works across both backends, and
requires less moving pieces to have it get the right results.
Concretely, fixes size detection on X11/libinput, which makes touchscreen
mapping go wrong.
https://gitlab.gnome.org/GNOME/mutter/issues/514
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
When we floor the quad coordinates then we've also to enlarge the quad by the
difference between the floored value and the actual coordinate, otherwise
we'd end up in a smaller quad.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
Make the RecordWindow method also understand the 'cursor-mode' property.
For 'embedded' the cursor is drawn onto the pixel buffer using cairo,
otherwise it works similarly to how RecordMonitor deals with it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/413
To be used to translate absolute cursor positions to relative positions,
as well as to determine whether a cursor sprite is inside the stream or
not. It also helps calculating the scale the cursor sprite needs to be
scaled with to be in stream coordinate space.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/413
As the stream size is the logical monitor size multiplied with the ceil
of the logical monitor scale, the corresponding logical size, which is
what should be passed via the size property on the D-Bus object, should
be the logical monitor size.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/413
Make the monitor implementation do things strictly related to its own
source type, leaving the Spa related logic and cursor read back in the
generic layer, later to be reused by the window source type
implementation.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/413
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
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
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
The signal handler must return TRUE as the invocation is already handled
by returning an error. Also update the error message a bit to clarify
that the API exists only for testing purposes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/457
We should not only take the old CRTC for an output whenever
possible, but we should also assign one that is 'free', i.e.
one that another monitor (to be processed after this one)
isn't using, so that that monitor can use the same CRTC.
https://gitlab.gnome.org/GNOME/mutter/issues/373
We shouldn't change an output's CRTC if we don't have to, as
that causes the output to go black.
This patch depends on
"monitor-unit-tests: initial crtcs in custom_lid_switch".
https://gitlab.gnome.org/GNOME/mutter/issues/373
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.
Iterate over all the monitor product words to check for a partial matching on
EDID, otherwise we would hang inside an infinite while loop.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/459
The helper function from gdbus-codegen broadcasts the signal emission,
but we really only care about sending it to the specific peer that
created the session. Thus, only emit the signal to the particular peer
that owns the session.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
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
This avoids having to hardcode the same fallbacks elsewhere multiple
times when determining what formats might be suitable for a set of
CRTCs. The formats_modifiers hash table is now guaranteed to be
populated with at least something, so future code will not need to
handle it being empty.
The hardcoded fallback formats are a minimal set probably supported by
most hardware. XRGB8888 is the format that, according to ancient lore,
all DRM devices should support, especially if they don't have the
capability to advertise otherwise. Mutter also hardcodes XRGB8888 as the
GBM surface format, so it is already required on primary GPUs.
XBGR8888 matches the most common OpenGL format, sans alpha channel since
scanout hardware has not traditionally supported alpha. XBGR8888 is here
also because Mutter hardcodes that format for secondary GPU outputs when
using the CPU copy path.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/341
If the IN_FORMATS property is not found, copy the formats from the DRM
plane instead. This is the fallback for getting a list of formats the
primary plane supports when DRM universal planes capability is enabled.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/341
Rather than picking just one format, parse and store all the formats and
their modifiers.
This gives us a list of supported formats (and modifiers) on a CRTC
primary plane. Later I will be using this list to choose a framebuffer
format instead of hardcoding it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/341
It scaled the logical monitor rect with scale to get the stream
dimensions, but that is only valid when having
'scale-monitor-framebuffers' enabled. Even when it was, it didn't work
properly, as clutter_stage_capture_into() doesn't work properly with
scaled monitor framebuffers yet.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/415
Commit 25f416c13d added additional compilation warnings, including
-Werror=return-type. There are several places where this results
in build failures if `g_assert_not_reached()` is disabled at compile
time and the compiler misses a return value.
https://gitlab.gnome.org/GNOME/mutter/issues/447
Shell is using these, which was revealed by
1bbb5c8107 breaking its build when
generating its introspection due to meta_startup_notification_get_type()
not being found.
We keep the class structs private, so in practice MetaStartupSequence
and MetaBackend can't be derived from (the are semi-private).
Make meson link libmutter using -fvisibility=hidden, and introduce META_EXPORT
and META_EXPORT_TEST defines to mark a symbols as visible.
The TEST version is meant to be used to flag symbols that are only used
internally by mutter tests, but that should not be considered public API.
This allows us to be more precise in selecting what is exported and what is
not, without the need of a version-script file that would be more complicated
to maintain.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was
causing introspection to see this like a GDBus skeleton object exposing to
clients methods that were not required.
Also, this required us to export meta_dbus_* symbols to the library, while
these should be actually private.
So, make MetaMonitorManager to be just a simple GObject holding a skeleton
instance, and connect to its signals reusing most of the code with just few
minor changes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
As with the commits earlier, this also adds const qualifiers where
expected. However, the const variables are casted to non-const variants
so they can be passed to glib functions that take non-const variants but
expect const-like input.
The 'cursor-mode', which currently is limited to RecordMonitor(), allows
the user to either do screen casts where the cursor is hidden, embedded
in the framebuffer, or sent as PipeWire stream metadata.
The latter allows the user to get cursor updates sent, including the
cursor sprite, without requiring a stage paint each frame. Currently
this is done by using the cursor sprite texture, and either reading
directly from, or drawing to an offscreen framebuffer which is read from
instead, in case the texture is scaled.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/357
There may be reasons to temporarly inhibit the HW cursor under certain
circumstances. Allow adding such inhibitations by adding API to the
cursor renderer to allow API users to add generic inhibitors with
whatever logic is deemed necessary.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/357
To get a consistent behaviour no matter whether HW cursors are in use or
not, make sure to copy the framebuffer content before the stage overlays
(cursor sprite textures) are painted.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/357
Mutter prefers platform devices over anything else as the primary GPU.
This will not work too well, when a platform device does not actually
have a rendering GPU but is a display-only device. An example of this
are DisplayLink devices with the proprietary driver stack, which exposes
a DRM KMS platform device but without any rendering driver.
Mutter cannot rely on EGL init failing on such devices either, because
nowadays Mesa supports software renderers on GBM, so the initialization
may well succeed.
The hardware rendering capability is recognized by matching the GL
renderer string to the known Mesa software renderers. At this time,
there is no better alternative to detecting this.
The secondary GPU data is abused for the GL renderer, as the Cogl
context may not have been created yet. Also, the Cogl context would
only be created on the primary GPU, but at this point the primary GPU
has not been chosen yet. Hence, GPU copy path GL context is used as a
proxy and predictor of what the Cogl context might be if it was created.
Mind, that even the GL flavour are not the same between Cogl and
secondary contexts, so this is stretch but it should be just enough.
The logic to choose the primary GPU is changed to always prefer hardware
rendering devices while also maintaining the old order of preferring
platform over boot_vga devices.
Co-authored by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
Moves the primary GPU choosing to after all secondary gpu data has been
created.
This makes it possible for a future patch to start looking at secondary
gpu data in choose_primary_gpu () to determine if it is using a hardware
driver or a software renderer.
Co-authored by: Pekka Paalanen <pekka.paalanen@collabora.com>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
Initialize the secondary GPU data for all GPUs, even the primary one. By
not looking at the primary_gpu_kms member, a future patch is allowed to
postpone choosing the primary GPU.
A future patch will use the secondary GPU data to decide which GPU will
become the primary GPU.
Co-authored by: Pekka Paalanen <pekka.paalanen@collabora.com>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
create_renderer_gpu_data_egl_device () relied on the primary GPU being
already chosen for the "EGLDevice currently only works with single GPU
systems" error message. A future patch will choose the primary GPU after
this, not before, so this check needs to be rewritten before the
initialization order is changed.
The new check is implemented exactly as the error message says: there
must be exactly one GPU, otherwise fail.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
Make the choosing and identity of the primary GPU an internal detail to
the native renderer. MonitorManagerKms did not need it for anything.
The primary GPU logic remains unchanged.
This allows follow-up patches to change how the renderer chooses the
primary GPU. It will be easier for the renderer to use private
information for choosing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
This is a step towards moving the primary GPU logic into the native
renderer exclusively. In the future the renderer will have one more
criterion on choosing the primary GPU than MetaMonitorManagerKms should
know about: does a GPU offer hardware rendering.
The choosing of primary GPU is separated from the discovery of GPUs.
When GPUs are discovered and added to the list, the MetaGpuKmsFlag is
now populated correctly and used in choosing.
Choosing the primary GPU is done after all GPUs have been found and is
slightly different from before:
- Skipping devices that do not belong to our seat now works instead of
becoming the primary GPU.
- Fall back to any non-platform, non-boot_vga device if neither kind is
found.
The old preference of platform over boot_vga device is kept.
The hotplug path will continue creating a gpu_kms without flags, because
at that point the primary GPU has already been chosen and the flags are
irrelevant.
Co-authored by: Pekka Paalanen <pekka.paalanen@collabora.com>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
Add a flags field to MetaGpuKms. In following commits, the flags defined
here will be set and used for choosing the primary GPU.
Co-authored by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
If a KMS device has the DRM_CAP_DUMB_PREFER_SHADOW and a software based
GL driver is used, always use a shadow fb. This will speed up read backs
in the llvmpipe OpenGL implementation, making blend operations faster.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/106
DRM_EVENT_CONTEXT_VERSION is the latest context version supported by
whatever version of libdrm is present. Mutter was blindly asserting it
supported whatever version that may be, even if it actually didn't.
With libdrm 2.4.78, setting a higher context version than 2 will attempt
to call the page_flip_handler2 vfunc if it was non-NULL, which being a
random chunk of stack memory, it might well have been.
Set the version as 2, which should be bumped only with the appropriate
version checks.
https://bugzilla.gnome.org/show_bug.cgi?id=781034
The Wacom Xorg driver assigns a serial number of 1 for any pad that doesn't
have a serial. libinput assigns 0. Just treat 1 as 0 here, there are no pens
with a real serial 1 anyway.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/414
Typically, to stream the content of a window, we need a way to copy the
content of its window-actor into a buffer, transform relative input
coordinates to relative position within the window-actor and a mean to
get the window bounds within the buffer.
For this purpose, add a new GType interface `MetaScreenCastWindow` with
the methods needed for screen-cast window mode:
* meta_screen_cast_window_get_buffer_bounds()
* meta_screen_cast_window_get_frame_bounds()
* meta_screen_cast_window_transform_relative_position()
* meta_screen_cast_window_capture_into()
This interface is meant to be implemented by `MetaWindowActor` which has
access to all the necessary bits to implement them.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/306
To be able to cast windows, which by definition can change in size
dynamically, we need a way to specify the video crop meta to adjust to
the window size whenever it changes.
Add VideoCrop support with a new optional hook `get_videocrop()` in the
`ScreenCastStreamSrcClass` which, if defined, can let the child specify
a rectangle for the video cropping area.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/306
Switch-configs are only to be used in certain circumstances (see
meta_monitor_manager_can_switch_config()) so when ensuring
configuration and attempting to create a linear configuration, use the
linear configuration constructor function directly without going via the
switch config method, otherwise we might incorrectly fall back to the
fallback configuration (only enable primary monitor).
This is a regression introduced by 6267732bec.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/342
Which eliminates the 1px jitter that was visible when dragging windows,
and eliminates the flickering that was visible when pushing the cursor
against the right/bottom edges of the screen.
If a display device (touchscreen, tablet with libwacom integration flags)
does not receive a monitor through settings. Delegate on the
MetaInputMapper so it receives a mapping through heuristics.
This object takes care of mapping absolute devices to monitors,
to do so it uses 3 heuristics, in this order of preference:
- If a device is known to be builtin, it's assigned to the
builtin monitor.
- If input device and monitor match sizes (with an error margin
of 5%)
- If input device name and monitor vendor/product in EDID match
somehow (from "full", through "partial", to just "vendor")
The most favorable outputs are then assigned to each device, making
sure not to assign two devices of the same kind to the same output.
This object replaces (and is mostly 1:1 with) GsdDeviceMapper in
g-s-d. That object would perform these same heuristics, and let
mutter indirectly know through settings changes. This object allows
doing the same in-process.
Since now we don't set the swap throttled value based
on sync-to-vblank, we can effectively remove it from
Cogl. Throttling swap buffers in Cogl is as much a
historical artifact as sync-to-vblank. Furthermore,
it doesn't make sense to disable it on a compositor,
which is the case with the embedded Cogl.
In addition to that, the winsys vfunc for updating
whenever swap throttling changes could also be removed,
since swap throttling is always enabled now.
Removing it means less code, less branches when running,
and one less config option to deal with.
This also removes the micro-perf test, since it doesn't
make sense for the case where Cogl is embedded into the
compositor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/191
Externally setting the sync-to-vblank setting was a feature
added as a workaround to old Intel and ATI graphic cards, and
is not needed anymore. Furthermore, it doesn't make sense to
change it on a compositor whatsoever.
This commit removes all the ways to externally change this
setting, as well as the now unused API.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/191
The nested stage tries to emulate how CRTCs are drawn, but fails to do
this when a stage view is scaled as it didn't adapt the viewport size
according to the stage view scale.
https://bugzilla.gnome.org/show_bug.cgi?id=786663
Add MUTTER_DEBUG_DUMMY_MONITORS_SPECS env variable support so that you can define
a ':' separated list of monitor specs in the form of WWWxHHH@RR that will be
available for configuring the nested mutter.
When calculating the logical monitor layout size given a scale, don't
risk precision loss by float to int casting, which could result in a too
small layout.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
We haven't supported disabling stage views in the native backend since
commit 70edc7dda4
Author: Jonas Ådahl <jadahl@gmail.com>
Date: Mon Jul 24 12:31:32 2017 +0800
backends/native: Stop supporting stage views being disabled
There were still some left over checks; lets remove them.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/343
Modal ungrabs may be followed by other clients trying to grab themselves,
flush the connection so we ensure the right order of events on the Xserver
side.
An example of this is js/ui/modalDialog.js in gnome-shell, as the alt-F2
dialog may launch X11 clients trying to grab themselves, commit a40daa3c22
in gnome-shell handled the case and added a gdk_display_sync() call to
ensure no grab existed at the time of executing.
This commit aims to achieve the same built in MetaBackend. A full sync
seems excessive though, as we just need to make sure the server got the
messages queued before the other side tries to grab, a XFlush seems
sufficient for this.
The nested backend used the value from udev, meaning that one couldn't
configure the fake monitor if the laptop panel of the host was closed.
Avoid this annoyance by always having the nested backend claiming the
lid is open.
It wasn't implemented by any subclass, it's not provided by DRM either.
And even if a subclass were to have only a file available, it could read
it into a GBytes as well and just use `read_edid()`.
Found this while working on !269.
Because it is implemented and always on. By advertising this fact
the master clock is able to sync to the native refresh rate instead
of always using the fallback of 60.00Hz.
https://bugzilla.gnome.org/show_bug.cgi?id=781296
Add support for getting hardware presentation times from KMS (Wayland
sessions). Also implement cogl_get_clock_time which is required to compare
and judge the age of presentation timestamps.
For single monitor systems this is straightforward. For multi-monitor
systems though we have to choose a display to sync to. The compositor
already partially solves this for us in the case of only one display
updating because it will only use the subset of monitors that are
changing. In the case of multiple monitors consuming the same frame
concurrently however, we choose the fastest one (in use at the time).
Note however that we also need !73 to land in order to fully realize
multiple monitors running at full speed.
Use cogl_framebuffer_read_pixels_into_bitmap () instead of
glReadPixels () for the CPU copy path in multi-GPU support.
The cogl function employs several tricks to make the read-pixels as fast
as possible and does the y-flip as necessary. This should make the copy
more performant over all kinds of hardware.
This is expected to be used on virtual outputs (e.g. DisplayLink USB
docks and monitors) foremost, where the dumb buffer memory is just
regular system memory. If the dumb buffer memory is somehow slow, like
residing in discrete VRAM or having an unexpected caching mode, it may
be possible for the cogl function perform worse because it might do the
y-flip in-place in the dumb buffer. Hopefully that does not happen in
any practical scenario.
Calling meta_renderer_native_gles3_read_pixels () here was conceptually
wrong to begin with because it was done with the Cogl GL context of the
primary GPU, not on the GL ES 3 context of a secondary GPU. However,
due eglBindAPI being a no-op in Mesa and the glReadPixels () arguments
being compatible, it worked.
This patch adds a pixel format conversion table between DRM and Cogl
formats. It contains more formats than absolutely necessary and the
texture components field which is currently unused for completeness. See
Mutter issue #323. Making the table more complete documents better how
the pixel formats actually map so that posterity should be less likely
to be confused. This table could be shared with
shm_buffer_get_cogl_pixel_format () as well, but not with
meta_wayland_dma_buf_buffer_attach ().
On HP ProBook 4520s laptop (Mesa DRI Intel(R) Ironlake Mobile, Mesa
18.0.5), without this patch copy_shared_framebuffer_cpu () for a
DisplayLink output takes 5 seconds with a 1080p frame. Obviously that
makes Mutter and gnome-shell completely unusable. With this patch, that
function takes 13-18 ms which makes it usable if not fluent.
On Intel i7-4790 (Mesa DRI Intel(R) Haswell Desktop) machine, this patch
makes no significant difference (the copy takes 4-5 ms).
The format will be needed in a following commit in the CPU copy path
which stops hardcoding another format and starts using the format the
dumb FB was created with.
Change the callers of init_dumb_fb () to use DRM format codes. DRM and
GBM format codes are identical, but since this is about dumb buffers,
DRM formats fit better.
The header /usr/include/gbm.h installed by Mesa says:
* The FourCC format codes are taken from the drm_fourcc.h definition, and
* re-namespaced. New GBM formats must not be added, unless they are
* identical ports from drm_fourcc.
That refers to the GBM_FORMAT_* codes.
Virtual keyboard and pointer are freed on session close, but the
virtual touchscreen isn't.
Avoid a leak by freeing the virtual touchscreen along with the rest of
virtual devices.
We were using the connector_id for the winsys_id, but different
devices could have connectors with the same id. Since we use
winsys_id to uniquely identify outputs, use both the connector
id and the device id to avoid having outputs with the same id.
Python is not guaranteed to be installed in /usr/bin. This is especially
true for *BSD systems which don't consider Python as an integral part of
their systems.
Don't schedule redraws when being headless; there is nothing to draw so
don't attempt to draw. This also makes a flaky test become non-flaky, as
it previously spuriously got warnings due to windows being "painted"
when headless but lacking frame timings, as nothing was actually
painted.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/170
The empty MetaStage was in meta-stage-private.h for no reason, so lets
move it to the C file. This makes it pointless to have a private
instance struct, so just move the fields to the private struct
_MetaStage.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/170
While leaving the runtime checks in place, requiring xrandr 1.5 at build
time allows us to remove some seemingly unnecessary conditional
inclusion of functionality.
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.
drmModePageFlip() is guaranteed to fail for the invalid FB id 0.
Therefore it never makes sense to call this function with such argument.
Disabling a CRTC must be done with SetCrtc instead, for example.
Trying to flip to FB 0 not only fails, but it also causes Mutter to
never try page flip on this output again, using drmModeSetCrtc()
instead.
There was a race in setting next_fb_id when a secondary GPU was using
the CPU copy path. Losing this race caused the attempt to
drmModePageFlip () to FB ID 0 which is invalid and always fails. Failing
to flip causes Mutter to fall back to drmModeSetCrtc () permanently.
In meta_onscreen_native_swap_buffers_with_damage ():
- update_secondary_gpu_state_pre_swap_buffers ()
- copy_shared_framebuffer_cpu () but only on the CPU copy path
- secondary_gpu_state->gbm.next_fb_id is set
- wait_for_pending_flips ()
- Waits for any remaining page flip events and executes and destroys
the related page flip closures.
- on_crtc_flipped ()
- meta_onscreen_native_swap_drm_fb ()
- swap_secondary_drm_fb ()
- secondary_gpu_state->gbm.next_fb_id = 0;
- meta_onscreen_native_flip_crtcs ()
- meta_onscreen_native_flip_crtc ()
- meta_gpu_kms_flip_crtc () gets called with fb_id = 0
This race was observed lost when running 'mutter --wayland' on a machine
with two outputs on Intel and one output on DisplayLink USB dock, and
wiggling around a weston-terminal window between the Intel and
DisplayLink outputs. It took from a second to a minute to trigger. For
testing with DisplayLink outputs Mutter also needed a patch to take the
DisplayLink output into use, as it would have otherwise been ignored
being a platform device rather than a PCI device.
Fix this race by first waiting for pending flips and only then
proceeding with the swap operations. This should be safe, because the
pending flips could have completed already before entering
meta_onscreen_native_swap_buffers_with_damage ().
When constructing MetaMonitorsConfig objects, store which type
of switch_config they are for (or UNKNOWN if it is not such
type of config).
Stop unconditionally setting current_switch_config to UNKNOWN when
handling monitors changed events. Instead, set it to the switch_config
type stored in the MonitorsConfig in the codepath that updates logical
state. In addition to being called in the hotplug case along the same
code flow that generates monitors changed events, this is also called
in the coldplug case where a secondary monitor was connected before
mutter was started.
When creating the default linear display config, create it as a
switch_config so that internal state gets updated to represent
linear mode when this config is used.
The previous behaviour of unconditionally resetting current_switch_config
to UNKNOWN was breaking the internal state machine for display config
switching, causing misbehaviour in gnome-shell's switchMonitor UI when
using display switch hotkeys. The lack of internal tracking when the
displays are already in the default "Join Displays" linear mode was
then causing the first display switch hotkey press to do nothing
(it would attempt to select "Join Displays" mode, but that was already
active).
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/281https://gitlab.gnome.org/GNOME/mutter/merge_requests/213
meta_renderer_native_gles3_read_pixels() was assuming that the target
buffer stride == width * 4. This is not generally true. When a DRM
driver allocates a dumb buffer, it is free to choose a stride so that
the buffer can actually work on the hardware.
Record the driver chosen stride in MetaDumbBuffer, and use it in the CPU
copy path. This should fix any possible stride issues in
meta_renderer_native_gles3_read_pixels().
Track the allocated dumb buffer size in MetaDumbBuffer. Assert that the
size is as expected in copy_shared_framebuffer_cpu().
This is just to ensure that Cogl and the real size match. The size from
Cogl was used in the copy, so getting that wrong might have written
beyond the allocation.
This is a safety measure and has not been observed to happen yet.
If drmModeAddFB2() does not work, the fallback to drmModeAddFB() can
only handle a single specific format. Make sure the requested format is
that one format, and fail the operation otherwise.
This should at least makes the failure mode obvious on such old systems
where the kernel does not support AddFB2, rather than producing wrong
colors.
Previously, trackballs were detected based on the presence of the
substring "trackball" in the device name. This had the downside of
missing devices, such as the Kensington Expert Mouse, which don't have
"trackball" in their names.
Rather than depending on the device name, use the ID_INPUT_TRACKBALL
property from udev to determine whether or not to treat a device as a
trackball.
This adds a new function, `is_trackball_device`, to MetaInputEvents, and
eliminates the `meta_input_device_is_trackball` function.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/258
The "backends: Move MetaOutput::crtc field into private struct"
accidentally changed the view transform calculation code to assume that
"MetaCrtc::transform" corresponds to the transform of the CRTC; so is
not the case yet; one must calculate the transform from the logical
monitor, and check whether it is supported by the CRTC using
meta_monitor_manager_is_transform_handled(). This commit restores the
old behaviour that doesn't use MetaCrtc::transform when calculating the
view transform.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/216
We need a way for mutter to exit if no available GPUs are going to work.
For example if gdm starts gnome-shell and we're using a DRM driver that
doesn't work with KMS then we should exit so that GDM can try with Xorg,
rather than operating in headless mode.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/223
meta_backend_x11_grab_device is performing X server clock comparison
using the MAX macro, which comes down to a simple greater-than.
Use XSERVER_TIME_IS_BEFORE, which is a better macro for X server
clock comparisons, as it accounts for 32-bit wrap-around.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/174
Commit c0d9b08ef9 replaced the old GBM API calls
with the multi-plane GBM API. However, the call to gbm_bo_get_handle_for_plane
fails for some DRI drivers (in particular i915). Due to missing error checks,
the subsequent call to drmModeAddFB[2] fails and the screen output locks up.
This commit adds the missing error checks and falls back to the old GBM API
(non-planar) if necessary.
v5: test success of gbm_bo_get_handle_for_plane instead of errno
This commit adopts solution proposed by Daniel van Vugt to check the return
value of gbm_bo_get_handle_for_plane on plane 0 and fall back to old
non-planar method if the call fails. This removes the errno check (for
ENOSYS) that could abort if mesa ever sets a different value.
Related to: https://gitlab.gnome.org/GNOME/mutter/issues/127
The function is intentionally provided as macro to not require a
cast. Recently the macro was improved to check that the passed in
pointer matches the free function, so the cast to GDestroyNotify
is now even harmful.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
For historical reasons meta_monitor_is_active() checked whether it is
active by checking whether the main output have a CRTC assigned and
whether that CRTC has a current mode. At a later point, the MetaMonitor
got its own mode abstraction (MetaMonitorMode), but
meta_monitor_is_active() was never updated to use this.
An issue with checking the main output's CRTC state is that, if there is
some CRTC mode combination that for some reason isn't properly detected
by the MetaMonitorMode abstraction (e.g. some tiling configuration not
yet handled), meta_monitor_is_active() would return TRUE, even though no
(abstracted) mode was set. This would cause confusion here and there,
leading to NULL pointer dereferences due to the assumption that if a
monitor is active, it has an active mode.
Instead, change meta_monitor_is_active() to directly check the current
monitor mode, and log a warning if the main output still happen to have
a CRTC with a mode assigned to it. This way, when an not undrestood CRTC
mode combination is encountered, instead of dereferencing NULL pointers,
simply assume the monitor is not active, which means that it will not be
managed or rendered by mutter at all.
https://gitlab.gnome.org/GNOME/mutter/issues/130
Avoid exporting through org.gnome.Mutter.DisplayConfig.GetCurrentState
excessively-low screen resolutions setting both a minimum width and a minimum
height. GetCurrentState is e.g. used by Gnome Control Center to build a list of
selectable resolutions.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=793223
If drmModeSetCrtc() is called with no fb, mode or connectors for some
CRTC it may still fail, and we should handle that gracefully instead of
assuming it failed to set a non-disabled state.
Closes https://gitlab.gnome.org/GNOME/mutter/issues/70
Add API to let GNOME Shell have the ability to get notified about remote
access sessions (remote desktop, remote control and screen cast), and
with a way to close them.
This is done by adding an abstraction above the remote desktop and
screen cast session objects, to avoid exposing their objects to outside
of mutter. Doing that would result in external parts holding references
to the objects, complicating their lifetimes. By using separate wrapper
objects, we avoid this issue all together.
Monitor whether UPower is running ourselves. That allows us to keep the
same value for "lid-is-closed" throughout the process of UPower
restarting, preventing unwanted monitor re-configuration through the process.
Fixes another screen black out when UPower restarts and the laptop lid
is closed.
Rather than handle UpClient in both MetaBackend (to reset the idletime
when the lid is opened), and in MetaMonitorManager and
MetaMonitorConfigManager (to turn the screen under the lid on/off
depending on its status), move the ability to get the lid status from
UPower or mock it in one place, in MetaBackend.
Restarting UPower will make every property of UpClient emit a "notify"
signal (as a GDBusProxy would). Avoid mutter reconfiguring the displays
when upower restarts by caching the last known value of "lid-is-closed"
and only reconfiguring the displays if it actually changed.
This fixes a black out of the screen when UPower restarts.
The framerate for screen cast sources was set to variable within 1 FPS
and the framerate of the monitor being screen casted. This meant that if
the sink didn't match the framerate (e.g. had a lower max framerate),
the formats would not match and a stream would not be established.
Allow letting the sink clamp the framerate range by setting it as
'unset', allowing it to be negotiated.
The PipeWire master branch saw some backports from the work branch,
including API changes making the 0.1 series more aligned with future
plans. Make mutter use the new API. This is needed to avoid dead locks
that existed in the older version.
Force update the cursor renderer after theme or size changes; otherwise
we'll be stuck with the old theme and/or size until something else
triggers resetting of the cursor.
