Correct dependency analysis for required DT_NEEDED entries is
made difficult due to the lack of DT_RPATH, despite all other
installed libraries in the build setting an RPATH.
Whilst it is true dlopen() still works, this is only because
libmutter is already linked to the main executable, which in turn
links to the private libraries via DT_RPATH.
Signed-off-by: Ikey Doherty <ikey@serpentos.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4150>
This allows drag-and-drop within the same surface with touch input.
Test case: drag-and-drop a file into a directory in Nautilus.
Prior to this change that would only work if the finger first leaves
then re-enters the surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4091>
On big endian machine, the native 32bits format is
DRM_FORMAT_BGRX8888, so add this format to the list.
Tested on a s390x VM, using virtio-gpu driver.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4088>
In try_create_context(), if COGL_EGL_WINSYS_FEATURE_NO_CONFIG_CONTEXT
is set, don't try to choose an egl config.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4088>
For zwp_text_input_v3_set_surrounding_text(), the protocol specifies:
"If the client is unaware of the text around the cursor, it should
not issue this request, to signify lack of support to the compositor."
Mutter currently doesn't clear its stored surrounding text when the
input focus changes, re-using the existing text for the newly focused
client. This already seems problematic, but since clients aren't
supposed to set surrounding text to NULL or an empty string if they
don't have one (and instead should simply avoid calling
`set_surrounding_text()`), this is clearly a bug in Mutter.
Fix it by unsetting the stored surrounding text when removing input
focus from a client.
Fixes: 33088d59db ("wayland/text-input: Pass char based offset to ClutterInputFocus")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3604>
In add_drm_device, calling g_hash_table_insert with NULL for the hash
table (which happens for any device added after mutter finished starting
up) would presumably just drop the key/value pointers on the floor,
leaking the string & MetaRenderDevice object referenced by them. Fixing
this should help for the referenced issue.
In meta_backend_native_take_render_device, g_hash_table_steal_extended
would presumably return FALSE (and log a warning), so the behaviour would
be "correct" by chance.
Issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/3785
Fixes: 58c3734d78e9 ("backend/native: Prepare render devices earlier than KMS")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4136>
When using a tablet tool in relative mode motion compression may
apply. Doing so drops the axes from the event, leading to a segfault
later when we're trying to broadcast_axis() an event without axes.
Fix this by making sure we copy the axes over during motion compression.
All but the wheel are absolute so we can just take them from the new
event but if we do have wheel data add them together and where the wheel
changes direction skip motion compression.
We can take a few shortcuts here because the clutter implementation
guarantees exactly CLUTTER_INPUT_AXIS_LAST axes so we only need to
put in warning checks in case that ever changes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3766
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4117>
The cursor and anchor position of the surrounding text *must* be within
(or right before/after) the string that is submitted as surrounding text.
Everything else is a client error that we shouldn't accept and log as such.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3650>
meta_wayland_text_input_focus_delete_surrounding() is accessible from JS and
used by gnome-shell via ClutterInputMethod.delete_surrounding(). Mutter
should never crash on invalid function calls from JS, so g_return_if_fail()
instead of asserting in case the parameters are wrong here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3650>
This allows to capture the next update of all stage views using
meta_backend_renderdoc_capture. Finer control over what stage view is
captured when can be added in the future.
Currently, renderdoc does not support the GL_OES_EGL_image extension
that we depend on for importing dma-bufs. This means that dma-buf
support is broken when mutter in launched with renderdoc.
One can hack up renderdoc to pretend to support GL_OES_EGL_image and
specifically EGLImageTargetTexture2DOES to restore the full mutter
functionality but renderdoc captures replay with a black rectangle where
those dma-buf buffers are being painted.
See:
https://registry.khronos.org/OpenGL/extensions/OES/OES_EGL_image.txthttps://registry.khronos.org/OpenGL/extensions/OES/OES_EGL_image_external.txt
It looks like the renderdoc maintainer does not want to merge support
for the extension: https://github.com/baldurk/renderdoc/pull/2845
We would only need support for dma-buf EGLImages which so it might be
possible to convince the maintainer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4061>
In contrast to realtime scheduling, this doesn't risk us getting
SIGKILL:ed when the kernel is doing busy looping in
drmModeAtomicCommit() for some reason, but will according to testing,
right now, give us more or less the same benefit when it comes to
dispatch lateness and commit lateness.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4124>
Either prefer "normal" or "realtime", via an enum, instead of a boolean.
Also make it configurable with an env var
`MUTTER_DEBUG_KMS_SCHEDULING_PRIORITY`, which can be set to either
`normal` or `realtime`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4124>
Overlays are always cursors, and "redraw overlay" doesn't communicate
that. Add "cursor" or "cursor overlay" to some functions to make it a
bit more obvious in a couple of places.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4066>
There were things hooked up (connecting signals, adding stage watches),
but it was a bit disorganized, with "adding watches" doing more, and
"init callbacks" being a bit vague. Split things up to
* setup view - hook up things that need to listen on a stage view
* setup cursor tracking - track cursor positions, sprite changes
* the rest - monitor changes etc
This also properly handles a race condition when we'll enable before the
idle callback creating the view from the virtual monitors is run.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4066>
The hardware cursor support in the cursor renderer now acts on a per
stage view basis, so no need to inhibit the hardware cursor, it isn't
going to try to put a hardware cursor on a virtual CRTC anyway.
Instead use overlay inhibitation to decide whether an cursor overlay
should be painted or not. Inhibit the overlay when hidden/metadata, but
not when embedded.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4066>
There's a workaround (ec18a559c687 ("monitor-manager: Ignore
tablet-mode-switch on initial config of native portrait mode panels")) for
panels that default to portrait mode, where touch mode is disabled, but
a touchscreen is present. This workaround gets applied when we receive
the first reading from the orientation manager.
Make sure this workaround is applied as expected by adding a test for it.
The test needs to be first in the list of orientation tests, because mutter
only applies the workaround on the first orientation event it receives.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4126>
The MetaWindowConfig can indicate whether the configuration reflects on
the initial configuration, before the window is first mapped.
Add a smaller helper (private) window function to create the appropriate
"type" of MetaWindowConfig depending whether the window was already
showed or not.
This is preparation work for the following commits where this function
will be used.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4076>
Use the meta_window_is_fullscreen() API instead of accessing the
fullscreen field of the MetaWindow structure directly.
This is both a (small) cleanup and preparation work for the next commit.
No function change (intended).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4076>
This is intended to be used in place of the window rect and fullscreen
flags.
That will also allow for a pre-configuration signal to be added, passing
the configuration so that a plugin can tweak the configuration before it
gets applied first.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4076>
Some laptops don't have the integrated GPU come earlier in the PCI topology
which means that when mutter enumerates the GPUs it may select the dGPU
as the primary.
In a laptop context, this is unlikely to work because the eDP panel can
only be actively connected to a single GPU at a time.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3746
Suggested-by: Jonas Ådahl
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4114>
The client may not wait for devices to be created before enabling,
meaning we might activate the input capture session before the device
emulation is started. This would result in events silently being
dropped.
This helps with the flaky input-capture test case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4128>
Since 1eba07f6 the size of a boxed value is read when calling
_cogl_boxed_value_set_x(). This results in an uninitialized read when
setting uniforms using cogl_pipeline_set_uniform_*() since the size was
not initialized by _cogl_pipeline_override_uniform() when these
functions call _cogl_boxed_value_set_*().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4125>
Use the 'seq' field in the spa_meta_header struct to track buffer
sequence numbers. This can be useful for predictable buffer tracking in
consumers, or for debugging purposes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4065>
This will become important when dispatching happens from a frame clock
driver, where the driver itself triggers from a GSource. If the driver
source has a higher priority, we'll risk dispatching before the frame
clock has returned to a state expecting to be dispatched.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4065>
