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>
