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 fec38819acc9a95a7ed18b8f103fb5d9a59c3c41 $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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
