Since the `switch` didn’t have a default case, the `cull_front` and
`cull_back` variables could technically be used uninitialised if the
`cull_mode` was unrecognised.
That seems unlikely to happen as presumably other code makes sure the
`cull_mode` is valid, but it doesn’t hurt to add a `default:` case to
squash the compiler warning.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3770>
Depending on whether the input mapper was found, these variables could
indeed be used uninitialised, so this is a true positive warning.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3770>
In the future, the module will automate uploading the release
tarball. We already use the CI pipeline to generate the tarball,
so it's easy to hook up the module and provide some testing
before the module goes into production.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3775>
We currently assume that the `CI_COMMIT_TAG` variable matches the
version component of the generated dist tarball.
That is usually correct, but sometimes errors happen and a wrong
tag is pushed, and the real release uses something like "46.0-real".
Account for that by building the artifact path from `meson introspect`
and exporting it as environment variable.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3775>
For a Wayland only build, we would like to avoid linking against
libXcursor which on it turn, links back to some of the X11 deps.
In order to achieve that, we include a small subset of xcursor.
In case Mutter is built with X11 or with both Wayland & X11, we link
against libXcursor and don't make use of the in-tree implementation.
This patch mimics what GTK 4 do by shipping an in-tree copy of xcursor.
Especially that libwayland-cursor does not provide an alternative to
xcursor itself.
Helps #2272
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3607>
When meta_wayland_pointer_constraint_remove() is called, it can trigger
a meta_wayland_event_handler_invalidate_focus() via:
meta_wayland_pointer_constraint_destroy()
meta_wayland_pointer_constraint_disable()
meta_wayland_input_detach_event_handler()
meta_wayland_input_invalidate_all_focus()
meta_wayland_event_handler_invalidate_focus()
Which then would result in a "focus-surface-changed" signal which would
call meta_wayland_pointer_constraint_remove() a second time. This
happens after surface_remove_pointer_constraints() has already been
called in the first meta_wayland_pointer_constraint_remove() call,
leading to "data" being NULL.
To prevent this issue disconnect the signal handler before calling
meta_wayland_pointer_constraint_disable() when destroying a constraint.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3476
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3749>
In case of empty regions (e.g. when locking the pointer) the pointer
was only forced to stay within the boundaries of its current pixel
(i.e. culling subpixel position), instead of the position where the
pointer lock did start.
Fixes: 07d24fe50 ("backends/native: Allow infinitely small pointer constraint regions")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3749>
Since 07d24fe50 regions are not translated to their on-screen
coordinates anymore, but are relative to the origin stored in the
constraint. This origin however was not considered when checking whether
the pointer was within the constraint region. This meant that the
constraint region would appear to always be placed at 0,0 instead of on
the surface.
Fix this by using the cursor position relative to the origin.
Fixes: 07d24fe50 ("backends/native: Allow infinitely small pointer constraint regions")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3409
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3749>
We close wayland popups when a button or touch release happens outside
of the grab, except we don't want to close them when that button release is
actually the release of the press that was opening the grab in the first
place.
We never see the press event that opened the grab, so the first event we
see is actually always a release. Make sure to not close the popup on that
event, and instead only close the popup if we see the press count drop from
1 to 0.
This fixes a bug where popup would close right after they open. To
reproduce, click to open a popup, hold pressed and move the cursor over
shell chrome, then release. Or alternatively test with a popup that gets
opened with a long-press gesture (eg. long touch long press on libadwaita
tabs), just doing the touch long-press and then release.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3631>
Until this surface or its parent is finalized.
This makes sure that any `MetaWaylandSubsurfacePlacementOp` referencing
this surface for sibling will be applied as intended.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3737>
This reverts commit 35d92e0fac.
This turned out to cause trouble, because it can prevent
MetaWaylandSurface::applied_state.subsurface_branch_node from ever
getting linked up for a sub-surface.
It shouldn't be necessary anyway, since permanently_unmap_subsurface /
wl_subcompositor_get_subsurface reset the sub-surface state as defined
by the protocol.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3737>
GSettings overrides can be active and set the default value depending on
the XDG_CURRENT_DESKTOP environement variable. For the tests we run, we
rely on the default settings by using the GSettings memory backend but
we also need to make sure not overrides are in place.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3730>
because we want to switch between two workspaces. In some configurations
there is only a single workspace at this point so trying to get current
workspace + 1 gets us a NULL pointer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3730>
The internal representation of the min/max width of windows include what
is outside of the window geometry, so when the window geometry changes,
but the min/max size did not in the same commit, we'd be left with an
out of date min/max size, potentially causing windows to shrink when
configured.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3755>
local_error in meta_egl_query_device_string() is using g_autoptr,
meaning that it was getting freed after g_propagate_error(). This then
would result in error->message becoming invalid, causing crashes when
logging the error message later on.
Fixes: 8234f5bc7 ("egl: Return success status from meta_egl_query_device_string")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3758>
Just shovel the data through our own stdin/stdout, which will end up at
the right place (e.g. /dev/null).
This should hopefully solve `mutter-dist` failing due to a D-Bus method
call timeout in CI.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3757>
An action can be performed both on a signal emitted by a window or by
a well-known signal name, so that one can do:
[window-id]::signal => command
And so these would work:
w/1::position-changed => resize w/2 20 30
::monitors-changed => move w/1 30 40
We only support "monitors-changed" global signal name or connecting to
window signals for now, but this can be easily expanded adding support
for more global signal values or parsing other kinds of object instances
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3701>
