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>
If the presentation time isn't known, e.g. if the monitor is virtual and
the actual presentation happens far away, the presentation time we
actually received tends to be the time a frame was presented to the next
layer, meaning practically immediately after painting.
When scheduling another update after that, don't assume that if the next
calculated update is not the immediate next update, schedule an update
sooner, as that will in such cases always be true, meaning we ended up
busy looping with constant frame updates being scheduled.
Fix this by only triggering that logic if the last presentation time was
actually vsync:ed.
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>
