This adds a copy of the calibration test profile and sets up a test to
first add it as a system profile, then setting up the XDG_DATA_HOME
directory so that the duplicate profile is detected, added, and later
discarded.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2622>
The D-Bus runner used by tests, including installed tests, is made to be
reusable from GNOME Shell. To do this, install it and the templates in
the pkgdatadir (e.g. /usr/share/mutter-APIVERSION/tests/), generate a
custom runner for the installed tests that uses the installed script and
templates, and change the non-installed original runner to use the
non-installed templates.
The end goal is to reuse the D-Bus session runner and templates used for
mutter when test running GNOME Shell.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1354>
This allows using two separate ICC profiles for one "color profile",
which is necessary to properly support color transform
calibration profiles from an EFI variable.
These types of profiles are intended to be applied using the color
transformation matrix (CTM) property on the output, which makes the
presented output match sRGB. In order to avoid color profile aware
clients making the wrong assumption, we must set the profile exposed
externally to be what is the expected perceived result, i.e. sRGB, while
still applying CTM from the real ICC profile.
The separation is done by introducing a MetaColorCalibration struct,
that is filled with relevant data. For profiles coming from EFI, a
created profile is practically an sRGB one, but the calibration data
comes from EFI, while for other profiles, the calibration data and the
ICC profile itself come from the same source.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2568>
This mocks gsd-colord to enable night ligth at a given temperature. The
test then verifies that the result exactly matches that of the gamma
ramps gsd-color generated for the same temperature and ICC profile.
There are two types of profiles tested; ones with VCGT, i.e. calibrated
profiles, and ones without. These are tested as the VCGT affects how the
gamma curve looks, while the non-VCGT profiles all only rely on
the blackbody temperature to generate a gamma ramp.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
We created device profiles, that we manage the lifetime of in colord,
but color devices can be assigned profiles other than the ones it was
created for. For example, this can include the standard sRGB profile
provided by colord.
To achieve this, keep track of the default profile of the CdDevice as
the "assigned" color profile of the device. Given this profile
(CdProfile), construct a MetaColorProfile that can then be interacted
with as if it was generated by ourself.
The assigned profile (default profile in colord terms) does nothing
special so far, but will later be used to determine how to apply CRTC
gamma ramps etc.
The sRGB.icc file used in the tests was copied from colord. It was
stated in the repository that it has no known copyright restrictions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
Just as gsd-color does, generate color profiles. This can either be done
from EFI, if available and the color device is associated with a built
in panel, or from the EDID. If no source for a profile is found, none is
created.
The ICC profiles are also stored on disk so that they can be read by
e.g. colord. The on disk stored profiles will only be used for storing,
not reading the profiles, as the autogenerated ones will no matter what
always be loaded to verify the on disk profiles are up to date. If a on
disk profile is not, it will be replaced. This is so that fixes or
improvements to the profile generation will be made available despite
having run an older version earlier.
After generating, add some metadata about the generated file itself
needed by colord, i.e. file MD5 checksum and the file path.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
Tests that test case EDID is setup correctly, and that color devices for
monitors are created.
tests/color: Add hotplugging tests
Checks that changing the number of connected monitors reflects the
number of current color devices, and that we end up with the correct end
state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
gsd-color provides this API, which exposes details about the night light
state. Currently, gsd-color also turns this state into CRTC gamma
changes, but this will eventually change, and this is a preparation for
this.
The proxy isn't yet used for anything.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
This will be needed for adding colord integration without breaking
testing.
The test context is altered to make sure any left over color devices are
cleaned up before starting. This means it becomes possible to run a test
case multiple times without having to restart meta-dbus-runner.py.
Note: Don't use os.getlogin() to get the current username; as that
requires a controlling terminal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
We fairly consistently had multiple monitors with the whole
vendor,product,serial tuple identical. If we start relying on making
monitors a bit more unique, e.g. for colord integration, we need to make
two monitors connected distinguishable in order for tests to properly
reflect reality and excercise the correct colord integration paths.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
Client connections may linger after the test driver is teared down;
handle this gracefully by unsetting the user data on the wl_resource,
and make the resource destructor a no-op, instead of where it would
otherwise remove itself from the resource list. This fixes this crash
seen in CI:
Received signal 11 (SIGSEGV)
#0 g_list_remove() at ../glib/glist.c:596
#1 test_driver_destructor() at ../src/tests/meta-wayland-test-driver.c:219
#2 destroy_resource() at ../src/wayland-server.c:730
#3 for_each_helper() at ../src/wayland-util.c:416
#4 wl_map_for_each() at ../src/wayland-util.c:430
#5 wl_client_destroy() at ../src/wayland-server.c:889
#6 wl_display_destroy_clients() at ../src/wayland-server.c:1482
#7 meta_wayland_compositor_prepare_shutdown() at ../src/wayland/meta-wayland.c:441
#8 meta_context_dispose() at ../src/core/meta-context.c:667
#9 g_object_unref() at ../gobject/gobject.c:3863
#9 g_object_unref() at ../gobject/gobject.c:3780
#10 glib_autoptr_clear_GObject() at /usr/include/glib-2.0/gobject/gobject-autocleanups.h:29
#10 glib_autoptr_clear_MetaContext() at ../src/meta/meta-context.h:32
#10 glib_autoptr_cleanup_MetaContext() at ../src/meta/meta-context.h:32
#10 main() at ../src/tests/wayland-unit-tests.c:707
#11 __libc_start_call_main() in /usr/lib64/libc.so.6
#12 __libc_start_main() in /usr/lib64/libc.so.6
#13 _start() in /builds/GNOME/mutter/build/src/tests/mutter-wayland-unit
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2601>
The catch option makes test run via 'catch'[1], which will log
backtraces whenever an abort or segmentation fault happens in any of the
subprocesses. The aim is to enable this when running in CI to help
debugging crashes that only tend to happen in CI.
While it's possible to wrap the whole meson command in 'catch', doing so
doesn't cover the KVM tests, so this option is added instead that covers
both cases.
[1] https://gitlab.gnome.org/jadahl/catch/
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2561>
Until recently, mutter-test-runner called into libraries that
indirectly depend on (mutter's fork of) Clutter, but did not actually
call into Clutter itself. Commit 1bf70334 "tests/runner: Make test
runner use the headless backend" gave it a direct call into Clutter,
which means the runtime linker will fail unless the executable's
RUNPATH is sufficient to find Clutter.
For future-proofing, do the same for the other test executables.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/2389
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2581>
If two modes are roughly the same, they should probably use the same UI
scaling factor. I.e. for the same monitor, if a 4K mode was configured to
have a certain scaling factor, and we generate a new configuration with
a similar sized 4K mode, we should re-use the scale previously
configured; however if we e.g. go from a 4K mode to a FHD mode, we
shouldn't.
This allows implementing better hueristics when using the switch-config
feature, where we'd be less likely to loose the for a certain monitor
mode combination previously configured scaling factor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
This checks that an unmapped but created Wayland window correctly handle
monitor changes. This is specifically added to test an edge case causing
a crash with the following backtrace:
```
...
4) 0x00007ffff78a2a6b in g_assertion_message_expr ()
5) 0x00007ffff7defd5b in meta_window_update_for_monitors_changed () at ../src/core/window.c:3745
6) 0x00007ffff7899758 in g_slist_foreach () at ../glib/gslist.c:885
7) 0x00007ffff7dbe562 in meta_display_foreach_window () at ../src/core/display.c:3185
8) 0x00007ffff7dbe5fd in on_monitors_changed_internal () at ../src/core/display.c:3210
9) 0x00007ffff796f4ff in g_closure_invoke () at ../gobject/gclosure.c:830
10) 0x00007ffff7981316 in signal_emit_unlocked_R () at ../gobject/gsignal.c:3740
11) 0x00007ffff7987699 in g_signal_emit_valist () at ../gobject/gsignal.c:3495
12) 0x00007ffff7987bc2 in g_signal_emit () at ../gobject/gsignal.c:3551
13) 0x00007ffff7d89915 in meta_monitor_manager_notify_monitors_changed () at ../src/backends/meta-monitor-manager.c:3517
...
```
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
The function finds a suitable logical monitor given the window
rectangle; this wasn't all that clear from the name
"calculate_main_logical_monitor".
This is in preparation for finding a new logical monitor using things
other than the geometry of the window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
This will allow tests to change monitor resolution. The first argument
is the monitor ID; there is always one monitor added by default, and it
has the id 0. It's currently not possible to add more monitors, so
passing '0' is the only valid way to resize monitors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
This hasn't worked for a while, since the test always runs the nested
backend, meaning it's a Wayland compositor. To unblock testing window
management in combination to monitor changes, lets remove the
unreachable X11 WM paths, so that we can start using virtual monitors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
It consists of only a macro and build description logic.
Adds a macro for simpler tests that doesn't require a context; unit
tests requiring a context should use the same framework as conform
tests.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2555>
All working tests have already migrated to the test suite using mutter;
move the old unported tests over too, and remove the conform test
framework, as it is no longer used.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2555>
This is in preparation of moving Cogl tests into src/tests, so they can
use the real backend, instead of the franken-backend it some how still
manages to use some how.
This makes them no longer installed. Most mutter tests are yet to be
installed, so leave that for later, since bigger changes are needed for
that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2555>
They can be quite heavy, as they load up one virtual machine each. If
your system is already busy, this can easily cause them to time out
instead of finish in time, as they all fight over the same limited
amount of CPU and I/O time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2556>
