Having an always-on-top window affects focus granting logic if the
to be showing window overlaps with any of them. Instead of triggering
the focus denying logic if a new window ever so slightly touches an
always-on-top window to only triggering if it's covered more than 60% by
always-on-top windows.
This is intended to make using always-on-top windows a bit less annoying
and not cause as many unintended focus-on-map denials.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3879>
When we show a window, we'll check if it overlaps with an existing
always-on-top window with the intention to deny focus. However, we did
this potentially before having placed the window, meaning we effectively
checked as if it was placed at (0, 0), which created unexpected results.
Instead check the overlap state after placing. A window placement test
case is added to verify this works as expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3879>
Replace a boolean argument and a temporary MetaWindow struct field with
a `MetaPlaceFlag` passed where relevant. This includes
`meta_window_move_resize_internal()` and `meta_window_constrain()`, as
placement may happen during constraining, and also
`meta_window_force_placement()`.
The struct field (denied_focus_and_not_transient) was only ever set in
meta_window_show(), before meta_window_force_placement(), and
immediately unset as a side effect of that. In .._show() we'll always
force placement if the window wasn't already placed, and in
meta_window_constrain(), we'd only ever call meta_window_place() if the
window wasn't already placed, meaning the variable would only ever be
relevant during `meta_window_show()`. Having it as a flag makes that
relationship and temporary state clearer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3879>
The function checking whether a 'always-on-top' window covers the
showing window now has that in the name, to make it more obvious. That
function was also changed to use the more common way of iterating a
list, and now uses auto cleanup pointers for the list.
The condition itself was updated to follow the current coding style.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3879>
It won't be used until later when we flip, and in fact assigning
it early could have led to its own assertion failing on the next frame
in the unlikely event that we return with "Failed to ensure KMS FB ID...
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3891>
This avoids the following critical warning happening sometimes when a
Wayland client exits taking all its window with it in an arbitrary
order:
CRITICAL: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3870>
This, in contrast to 'assert_stacking' only checks showing windows. This
is useful when doing workspace tests, where one want to check what
windows are currently visible.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3870>
When a transient window becomes transient, check if the parent is
sticky, and if it is, make the transient sticky as well. This handles
situations where e.g. a utility dialog (such as search and replace) is
opened on a sticky window, also making the utility dialog sharing the
same stickyness state.
This is also more in line with the semantics of making a window sticky,
where transient would implicitly become sticky as a side effect.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3870>
If a transient window is sticky (visible on all workspaces) and it gets
activated, we'd call move_worskpace() which would effectively unstick
it, which is rather unexpected. It'd also effectively unstick its parent
as well, due to moving a transient window also moves its descendants and
ascendants.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3870>
Introduced in libinput 1.26 this feature allows restricting the
tablet tool pressure range to a subset of its physical range. The
use-case is either to require some higher-than-usual minimum pressure
before the pen reacts, or lower-than-usual pressure to reach the maximum
logical pressure.
libinput takes a [0.0, 1.0] normalized range which we expose as percent
in the gsettings. The wacom driver doesn't have an exact equivalent but
it has a Threshold setting (range [1, 2048]) that defines when a button
is generated for tip down.
See gsettings-desktop-schemas!84
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3794>
This mapper hooks into CLUTTER_BUTTON_PRESS/RELEASE events with a
clutter button of zero but a nonzero evcode (e.g. BTN_STYLUS).
It then looks up the available button actions and implements
switch-monitor and keybindings using the MetaTabletActionMapper parent
class.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
Unlike most other schemas the path for a tool requires a bit of
processing (serial number or tablet vid/pid if there's no serial number).
Let's make the tool settings available through the MetaInputSettings
instead of having to duplicate that path composition in the caller.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
Stylus actions that don't map into LMR or back/forward are now created
as a clutter button event with a button number of zero. Nothing is
actually done with those events for now, they're just discarded later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
For stylus buttons we apply a button mapping, e.g. secondary button ->
right. This mapping was previously applied to the clutter event's evdev
code only, not the actual clutter button. As a result, gnome-shell would
always treat the BTN_STYLUS as middle and BTN_STYLUS2 as right,
regardless of the mapping.
Move the mapping up so we first adjust our evcode, then proceed with
the usual mappings.
Note that this temporary breaks the stylus mapping to Back/Forward which
will be fixed in a follow-up commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
Use the helper function for mapping a stylus tool evdev code to a
clutter button code. This fixes a (theoretical) issue - if a tool were
to send any button other than the one we handled those would likely be
BTN_SIDE and friends and we'd likely end up with negative button
numbers. The BTN_TOOL_PEN range is not predicable enough to do any sort
of calculation conversion because things like BTN_TOOL_DOUBLETAP have
specific meanings that aren't actually buttons.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
This complements the existing clutter->evdev and evdev->clutter helpers,
but this time for buttons we expect from a stylus tool. We also need to
convert left/middle/right for the Wacom puck/lens cursor tools but that
particular conversion is lossy.
Note that these are more restrictive than the normal codes - if we
get "other" buttons from a stylus we don't really know what they could
possibly map to. So we safely map what looks like buttons from a mouse
but otherwise complain and return zero.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
This is prep work for using the same functionality for tablet tools as
well. The new MetaTabletActionMapper takes care of the event bubbling
via the device-added/removed and input-event signals and provides the
helper functions to cycle outputs and/or emulate keybindings.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
Instead of using cairo for scaling and rotating cursors before putting
them on a plane, use Cogl. For now still download them back to the CPU
so we can place them on a dumb buffer, but can explore rendering to a
DMA buffer directly as a future improvement.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
This looks at the color state it got from the actor on construction, and
the target color state from the paint context and generates (and caches)
color aware pipelines used for painting. One of the purposes here is for
mixing SDR and HDR content and painting to a HDR monitor. If HDR (or
optical blending) isn't activated, the produced shaders will be
equivalent to what we had before.
Also add some names to the piplines, as this helps identifying what
pipeline source is associated with what pipeline.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
In some of the places we need more context than just the CoglContext, so
prepare for that by passing around the paint context, which carries
this, everywhere instead. It won't be needed everywhere, but lets stay
consistent.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
Color aware rendering needs shaders / pipelines that adapt to what
output they render to. For example if we want to render to a linear
BT.2020 intermediate framebuffer on one monitor, and a non-linear sRGB
direct target buffer on another, the shader for the same paint node or
content will depend on where they are going to be presented.
In order to help keeping track of what shader should target what
monitor, without having to regenerate them each time, introduce a
pipeline cache that knows how to handle differentiating between
transforming between different color state.
The cache is meant to handle caches for multiple pipeline users, where
each user might potentially want to keep track of multiple pipelines
itself. Lookup should be O(1), and in order to achieve this, separate
the cache into 3 levels.
The first level is the "pipeline group", where e.g. a ClutterContent
type allocates a group where it can store its pipelines. Each group has
a fixed number of "slots" where it can store a pipeline. Each slot has a
hash table where the key is derived from a color state transform, and
where the value is a CoglPipeline where the thame color state
transformation is expected to be handled.
A content will when painting know about its own color state, and the
target state it should render into, retrieve a cached pipeline for the
correct transform, or if the cache didn't have it, generate it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
Allow compositing in a linear color space and do so either when forcing
it via the debug controls D-Bus API, or when the experimental HDR mode
is enabled.
This relies on paint nodes etc to actually transform everything into the
linear target color space, which isn't done yet, so enabling it right
now will cause a broken result. Yet, introduce this now, so that
painting can be fixed piece by piece.
Linear blending is automatically enabled on monitors where HDR is
enabled, as this makes it possible to use an linear color space when
blending content from different color spaces with different transfer
functions.
Linear blending requires extra precision, i.e. 16 bit per channel
in the intermediate buffer due how the values are distributed,
so only enable the experimental HDR mode if the Cogl context supports
half float formats.
By default, no intermadiate linear offscreen framebuffer is used.
To test, do e.g.
./tools/debug-control.py --toggle ForceLinearBlending
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
The initial target color state is the color state of the stage view
being painted to. If we're painting to an arbitrary framebuffer, it's
currently hard coded to sRGB/electrical.
The content color state is not set on construction, but when starting to
paint, it's set to the color state of the stage itself. Whenever an
actor is painted, it'll set the color state to the color state of
itself. The intention is that offscreen rendering pushes a target color
state that causes painting to it to not necessarily be in the stage view
color state.
Pass color state with offscreen framebuffer, as this avoids hard coding
sRGB in the lower level bits of paint contexts. It's still practically
hard coded, only that it's derived from somewhere else (e.g. the stage
or window actor).
Nothing is actually using this yet, but will eventually.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
An unknown color space isn't very useful to have, as there is not very
actionable what to do with it. Rename it to 'default'. Later it'll be
used to an implicit color space, which in practice will be treated as
sRGB.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
g_unix_fd_list_append() duplicates the provided fd. If that fails, it
returns -1 as fd index and sets - if provided - the passed GError
accordingly.
However, currently, mutter does not check the return value (the fd index
of the appended fd) and thus passes an invalid fd list via dbus to the
remote desktop session user.
Fix this error by also checking the fd index. If the fd index is invalid
(< 0), simply pass the error message of the g_unix_fd_list_append() call
to the caller.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3871>
This reverts commit a3082b8eb3.
We don't find the VKMS device with this commit because it is on seat0
and not on META_BACKEND_TEST_INPUT_SEAT.
The other way around, i.e. returning seat0 in all cases also doesn't
work because *something* hangs if the default seat referrs to the real
seat0 instead of the nonesense META_BACKEND_TEST_INPUT_SEAT.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3869>
mktemp can create a tempfile relative to a directory passed in via -p.
It also uses the $TMPDIR variable for the same purpose. When the
template is specified via -t, $TMPDIR takes precedence over -p. When the
template is specified via a positional argument, -p takes precedence.
Since fec38819ac $TMPDIR is set via the
dbus runner which took precedence.
virtme-ng doesn't seem to share /tmp with the host system which results
in the exit status from the test in the VM not propagating back to the
test harness.
Fix that by making sure we always create the tempfile for the result in
the build directory.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3867>
Fixes error building against libdrm >= 2.4.122:
../src/backends/native/meta-kms-plane.c:67:8: error: redefinition of ‘struct drm_plane_size_hint’
67 | struct drm_plane_size_hint {
| ^~~~~~~~~~~~~~~~~~~
In file included from /usr/local/include/libdrm/drm.h:1025,
from /usr/local/include/xf86drm.h:40,
from ../src/backends/native/meta-kms-plane-private.h:20,
from ../src/backends/native/meta-kms-plane.c:21:
/usr/local/include/libdrm/drm_mode.h:866:8: note: originally defined here
866 | struct drm_plane_size_hint {
| ^~~~~~~~~~~~~~~~~~~
Suggested by Jonas Ådahl.
v2:
* Use has_type. (Sebastian Wick)
v3: (jadahl)
* Bump meson requirement to 1.3.0 for compiler.has_type()
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3556
Fixes: 0ca933baec ("backend/native: Adds support for SIZE_HINTS Cursor Plane Property")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3848>
This code is called from handlers connected to signals of a
MetaWindow. It cannot happen that the window will end up NULL
in these, so exchange with a g_assert() as we in fact expect
it to be non-NULL.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3860>
We cannot use a function with the same signature for signals with different
arguments, if we want to rely on the user data parameter. Separate into
two signal handlers calling the same function inside.
Fixes: b9ba34ac6f ("wayland/activation: Fix signal callback signature")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3860>
The two dialog creation virtual functions returned by these functions have to
be unreferenced by the caller (and are actually unreferenced in other places in
the code).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3790>
This gives greater control to the callers on the place where a grab is being
activated, this may make a difference in the handling of crossing events
triggered through it, e.g. by having callers rely on having already obtained
a ClutterGrab prior to handling the resulting effects.
The "input only" grab has also been turned inactive by default, in order to
to have the ClutterGrab pointer available for checks at the MetaWaylandEventHandler
focus changing methods triggered through grab activation.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3463
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3747>
If the titlebar of a window has been moved above the screen by a user
via an unconstrained move, then any constrained user resize following
this move will cause the window to jump below the top of the screen or
cause other glitchy behavior.
This commit removes the constraint that the titlebar of a window must be
below the top of the screen for any resize that is both (1) triggered by
a user and (2) is a resize that affects only the left, right, or bottom
edges of the window. This allows users to move a window partially above
the screen and then resize the window to be wider or resize the bottom
edge of the window to make it taller or shorter.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1206
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3764>
This unbreaks building here. The compilation error was due to
MetaX11Display having an incorrect typedef in a now preprocessed out
part, which will be fixed in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3851>
Allows gnome-shell or other compositors to detect which features
were built when building libmutter automatically without having to
expose various build options themselves
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3776>
Moving a window is a compositor action and happens immediately. Waiting
here is pointless. Make sure instead that the action happens immediately
by asserting the position.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3842>
wait and wait_configure after a single resize is useless and a race.
Resize is a client side action which doesn't result in a configure and a
wait doesn't sync for a resize as well.
Sometimes the resize is paired with another action, such as maximize,
fullscreen or show. In those cases a configure will be generated and a
previous resize is accounted for.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3842>
Commit e775052429 changed the code such that resetting the actor is done
when a surface role is assigned. The dnd surface assigned vfunc doesn't
chain up which means the code to reset the actor is never hit and the
dnd surface never shows up.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3540
Fixes: e775052429 ("wayland/actor-surface: Reset the actor on role-assignment")
In these checks, it's an important detail to preserve subpixel information
in order to correctly determine whether the coordinates are inside or
outside a view.
Otherwise, small enough motion towards the left/top might get rounded
to 0, be seen as "inside the view", and the pointer coordinates be allowed
to escape the viewport constraints.
This was figured out by Pascal Nowack before me, with a difference of
minutes. Credit where credit is due.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3530
Fixes: 6c972546f1 ("mtk: Add Rectangle.contains_point")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3820>
In meta_seat_impl_remove_virtual_input_device(), the 'device'
variable is first removed from MetaSeatImpl, then a "device
removed" event is generated with it.
The problem here is that, if this is the last reference of
'device', the removal from MetaSeatImpl will destroy it. Then
the freed variable will be used to create the "device removed"
event, which is a use-after-free situation.
Fix that by owning an extra ref to 'device' as long as the
function is executing. Do this by declaring a g_autoptr
variable with the extra ref. This g_autoptr variable is cleaned
up by the end of the function, which achieves the desired effect.
Spotted by Coverity.
CID: #1594046
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3835>
Right now the unmapped signal doesn't always fire which means we didn't
see a surface that's being unmapped in these code paths before. In
particular the resource, window and role can be gone. Handle those
cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3783>
This allows us one less level of indentation of all the tests. It is not
entirely true, the X11 backend test case script can run without it, but
it isn't valuable enough to run without the native backend being enabled
to complicate building.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3812>
Instead of having get_seat_id() handle most cases, and then special
casing another case outside of it, let it handle them all, making all
users just able to call get_seat_id().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3812>
Except the X11 backend test, it still needs an X server. Eventually we
can replace it with the equivalent that uses Xwayland, but that needs a
"scaled down" mutter that runs as the host compositor for Xwayland, that
doesn't expose anything on the session bus.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3812>
It's constructed as a native backend headless backend, but uses a custom
monitor manager (based on MetaMonitorManagerNative) that creates a fake
monitor. Rendering is unconditionally done with the surfaceless
renderer.
The test devices used now use virtual devices, meaning some changes to
the tests to e.g. not set names, and not dealing with input devices
directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3812>
This is where the viewports are updated, and so lets move connecting the
signal together with it. It also helps a future change to the test
backend where it creates a custom monitor manager.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3812>
Test touch devices are autocleaned up, but if a test case explicitly
needs it to be removed at a certain point, make sure to also clear the
pointer so that it doesn't get removed twice.
Right now it's harmless, but in a later commit it'll expected to only
remove a device once.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3812>
`update_secondary_gpu_state_post_swap_buffers` decides what our front
buffer object will be. There is only one answer. So return it as the
function result instead of making the caller figure it out.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3830>
It's always equal to `onscreen_native->next_frame` and we can't eliminate
that copy so easily. Removing the parameter removes all ambiguity about
where the next frame will come from.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3829>
Starting in mesa 24.1 (good in 24.0.9, bad in 24.1.1), the current
kernel somehow manages to hang our VKMS based tests. Let's update the
kernel so we can bump the CI image without running into those hangs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3826>
When a client wants to lease DRM resources, it will attach the list of
connectors is wants to lease and then submit the request.
Once the request is submitted, destroy the DRM lease request object.
Co-authored-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
When a new device is connected, register a new global for it.
When a device is gone, remove the global. Upon receiving this event,
the client should destroy any matching wp_drm_lease_device_v1 object.
To destroy a wp_drm_lease_device_v1 object, the client must first
issue a release request. Upon receiving this request, send a released
event and destroy the object.
Co-authored-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
When the list of connectors available for lease changes send
wp_drm_lease_device_v1.connector events for added connectors and
wp_drm_lease_connector_v1.withdrawn events for removed connectors,
followed by a wp_drm_lease_device_v1.done event.
Co-authored-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
After sending the drm_fd event, send zero, one or more connector events.
After all currently available connectors have been sent, send a
wp_drm_lease_device_v1.done event.
Co-authored-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
Add meta_kms_impl_device_open_non_privileged_fd() that returns a
non-master file descriptor for a MetaKmsImplDevice.
It'll be required to implement wp_drm_lease_device_v1_send_drm_fd() in a
future commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
The manager keeps track of which connectors are leasable in general,
which connectors and resources are already part of a lease, and keeps
track of when leases get revoked.
When leasing out connectors, the required drm resources to drive the
connectors are included in the lease as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
When a plane is leased, it is assigned to a CRTC which is leased. When
trying to find a primary plane for a modeset, skip the assigned planes
on leased CRTCs to avoid sharing the resources with the leased process.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
This allows us to keep track when primary and cursor plane assignments
on a CRTC are unassigned. With this commit, all planes which are
assigned are actually in use and can't be assigned to anything else.
We'll make use of that fact when we search for a leasable primary plane.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
The lease_objects function takes connectors, CRTCs and planes which are
turned into a drm lease. The resulting lease can be revoked with
revoke_lease. With list_lessees the currently active leases can be
queried.
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
With leasing, we will give another client control over connectors but
they also need a CRTC to drive them. Those CRTCs won't be available to
the desktop/monitor-manager.
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
Add an environment variable (MUTTER_DEBUG_LEASE_CONNECTORS) that allows
set a ":" separated list of connector names as available for lease.
The names of the connectors can be found in "/sys/class/drm".
To illustrate it with an example, the names of the connectors and its
status can be fetched with this command:
$ for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n "${con#*/card?-}: "; cat $p; done
DP-1: disconnected
DP-2: disconnected
DP-3: disconnected
DP-4: disconnected
DP-5: connected
DP-6: connected
DP-7: disconnected
eDP-1: connected
HDMI-A-1: disconnected
And, to set "DP-5" and "DP-6" available for lease, the environment
variable can be set like:
MUTTER_DEBUG_LEASE_CONNECTORS=DP-5:DP-6
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
This is intended to be used to filter out what connectors will be
available for lease, i.e. non-desktop ones.
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3746>
When mutter creates a dma-buf buffer for screencasting, the buffers
stride will, among other attributes, also be defined.
However, mutter currently only sets the buffer stride, when actually
recording a frame, but not when adding it.
This behaviour disallows screencast consumers (clients) to already
import the respective buffer (i.e. for Vulkan creating a VkImage for the
dma-buf image), as the stride is not yet communicated to the client.
Since the stride won't change after adding the respective buffer,
directly set the buffer stride, when adding the PipeWire buffer. This
allows screencast consumers (clients) to do optimizations in their
encoding paths.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3827>
meta_flush_input() creates and runs a main loop in order to block until the
input thread has flushed all its events. This main loop is created on the
default main context though (NULL is passed to g_main_loop_new()), which
means that while the main loop runs, the default main context is active (aka
stage updates will happen).
This causes an issue with tests, specifically when there already is a stage
update queued before running meta_flush_input(): meta_flush_input() will
(as expected) block until the input thread flushed all its events to the
main thread. But while that is happening, the main thread will be doing the
stage update that was already queued, without the new events (the input
thread is just starting to flush those). Then meta_flush_input() returns,
and in our test we see that the stage has been updated, except it wasn't
updated with the latest events. The test now continues and fails.
To fix the issue, make meta_flush_input() truly blocking, so that it only
flushes the input thread, but doesn't drive the global main context while
waiting for that. After the flushing is finished, tests must now manually
iterate the main context themselves to ensure that a stage update happens.
This breaks a few stacking tests, because "move_cursor_to" and "click" use
meta_flush_input() internally. For those commands we now need to dispatch
a stage update afterwards.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3807>
Let the ClutterFrame (or rather MetaFrameNative) own both the scanout
object and the framebuffer object, and let the frame itself live for as
long as it's needed. This allows to place fields that is related to a
single frame together, aiming to help reasoning about the lifetime of
the fields that were previously directly stored in MetaOnscreenNative.
Also take the opportunity to rename "current" to "presenting", to make
it clearer that frame's buffer is what is currently presenting to the
user.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3799>
It's possible to destory the xdg_toplevel and xdg_surface which removes
the surface role and then re-use the surface on a new toplevel.
Mutter used to not create new SurfaceActors for the new toplevel which
were then shared between the old and new toplevel. This happens because
the actors can stay around after the wl resource is destroyed (e.g. for
closing effects).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3667>
Instead of resetting in the xdg_surface.get_toplevel call.
It also changes XDG popus handling to deal with cases where the surface
was part of a window before, the same way the toplevel does.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3667>
Wayland tests also get kvm and tty test variants, but running tty tests
on your main session makes them fail. The intention for tty tests is to
skip when not run from a tty, so fix that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3811>
If view initialization fails then don't add the view, rather than
adding a dummy offscreen view. This avoids flooding the log with
offscreen frame clock confusion:
Before:
```
libmutter-WARNING **: 15:47:27.763: Failed to allocate onscreen framebuffer for /dev/dri/card0: Failed to allocate surface: Function not implemented
Clutter-WARNING **: 15:47:28.557: (../clutter/clutter/clutter-frame-clock.c:419):clutter_frame_clock_notify_presented: code should not be reached
Clutter-WARNING **: 15:47:28.563: (../clutter/clutter/clutter-frame-clock.c:419):clutter_frame_clock_notify_presented: code should not be reached
Clutter-WARNING **: 15:47:28.567: (../clutter/clutter/clutter-frame-clock.c:419):clutter_frame_clock_notify_presented: code should not be reached
(repeats forever)
```
After:
```
libmutter-WARNING **: 16:09:04.945: Failed to create view for Unknown 46" on None-1: Failed to allocate onscreen framebuffer for /dev/dri/card0: Failed to allocate surface: Function not implemented
```
Relates to:
https://launchpad.net/bugs/1967707https://gitlab.gnome.org/GNOME/mutter/-/issues/2489https://gitlab.gnome.org/GNOME/mutter/-/issues/2295
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3115>
AMD driver is buggy when it comes to generate textures of 1px height [1]
while this is not a mutter problem, we should not block on that either.
So, given that the test purpose is to check the journal flushing during
unref more than its behavior, we can still check this in all the drivers
keeping a warning in the AMD case.
See: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11269
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3793>
Some tests sadly behaves differently depending on the driver in use.
While this shouldn't happen we can't block on these driver issues, so
add a test utils private function to get the driver information so that
we can adapt test behavior depending on this.
This will allow to disable / enable tests at runtime instead of failing
in all the implementations, which is still better for catching
regressions in the parts we may be ignoring otherwise.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3793>
When running the tests in non-undefined mode we should skip the known
failing tests instead of the whole suite, so mark them as such so that
we can still run the tests partially checking the things that still
work, avoiding to regress on them too.
We also run the tests in normal mode so that we can ensure that the
failures are still happening in that way.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3793>
We need to use a different $XDG_RUNTIME_DIR path to be able to start most
tests in parallel, and we can use a temporary directory for that which python
cleans up when done.
Also, given that most of settings are stored in HOME use temporary one
for that too, to prevent mutter to fail because it may load some local
configuration (e.g. monitors.xml) that don't meet the expectations or
that may change the test behavior in an unexpected way.
As per this, CI needs to be adapted for new args handling
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3793>
When testing mutter using `META_DBUS_RUNNER_WRAPPER=rr` we may get a
not found-device error, given that it's not a case we support, we can
ignore it as we do with permission denied one, limiting this to the RR
case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3793>
Showing the stage always results in an initial update being queued. If the
virtual input events from the test ends up being dispatched after that, the
`wait_for_update()` checks gets out of sync, as the first update ended up
waiting for the initial update, not the one from the input event.
Fix the gesture test by adding another call to `wait_stage_updated()` right
after `clutter_actor_show()`.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3521
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3795>
Allow a screen cast stream source to say that nothing changed in terms
of cursor metadata, and treat this together with a cursor-only frame as
we not recording anything.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3803>
We're not doing anything significant in the KMS thread anyway, so don't
make it a kernel thread, and don't ask to be real time scheduled (which
we wouldn't be anyway, but for clarity).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3805>
Don't try to find the card, and then the render node from it, just ask
udev to list the render nodes directly. This avoids running into
permission errors when the user cannot open /dev/dri/card* even without
mode setting capabilities.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3805>
By turning a macro that exists in the codebase to a proper
function so that gnome-shell could make use of it as well
instead of using a region for it contains_point api...
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3801>
And also "completion" time to measure when the commit returned.
This is structured so as to measure all timestamps first before logging
anything. That way our results shouldn't be (don't seem to be) affected
by the logging itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3265>
While it should not be expected that we pick the pointer into a
MetaSurfaceActor that is disembodied of its MetaWaylandSurface/MetaWindow,
the paths where this should be enforced are somewhat scattered.
So account for the situation in picking code, and prefer a NULL surface
over a crash. This operates on the assumption that this inconsistent state
where Mutter didn't know better to pick a correct surface actor will be fixed
by later crossing events resolving the intermediate state, and that no
other input events will be received meanwhile.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3393
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3729>
When unmapping a subsurface, it does lose early its connection to the
parent surface. This is however a deciding factor in determining whether
the surface (role) has a window.
Make the subsurface actor unreactive if its connection to the parent
MetaWindow was severed, since it should not be eligible for picking anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3729>
These actors are expected to be destroyed along with their surface, this
however happens later in the process, so there is a moment where actors
are eligible for picking, but do not have a surface anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3729>
Prior to the grabs/focus rework in !3420, Wayland grabs were handled
separately from ClutterGrabs. This required explicitly checking for
ClutterGrabs as those were expected to prevent events from reaching
Wayland clients.
Now after !3420, Wayland client grabs also result in ClutterGrabs, which
means that this check causes input events for popups with grabs to not
get sent to ibus anymore. Instead the events are getting sent to the
client directly, which results no ibus support in popups (unless the
client handles that itself by using a different GTK_IM_MODULE).
However due to the changes from !3420 checking for ClutterGrabs is also
no longer necessary and the meta_wayland_text_input_update() focus check
is now sufficient to only forward events to ibus, when the focus is
actually on a Wayland client. So to fix this we can simply remove the
check.
Fixes: 2a584a8f0 ("wayland: Make use of Wayland event grabbing mechanism")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3502
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3787>
Reads exposed size hints for the given cursor plane. Chooses nearest
minimum cursor size out of the hints with respect to the user chosen
cursor size from the UI. Allocates optimized Hardare cursor size,
hence drm buffer
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3165>
Instead use an abstract "logical monitor id" that is generated from the
logical monitor. Instead of using low level numbers from the mode
setting devices, use either data from the EDID, or the connector, if the
EDID is not useful.
This should help with windows remembering monitor positions when the
same monitor reappears but with another mode setting device ID.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3753>
