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>
More or less copied from gnome-settings-daemon. The look up tables are
either calculated based on the VCGT (Video Card Gamma Table) and the
blackbody color for a given temperature, or the blackbody color for a
given temperature alone, if no VCGT is available.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
This means that e.g. custom profiles or calibrated profiles will be
added and registered with colord. This does not use CdIccStore for two
reasons: don't want to generate duplicate entries for auto-generated
EDID or EFI profiles, and we want to store profiles as MetaColorProfile.
It also happens to be the case that CdIcc does synchronous I/O, which
should be avoided everywhere except on startup.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
It will be used to generate gamma look up tables depending on
temperature.
The temperature comes from org.gnome.SettingsDaemon.Color and
depends on the current night light state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
It uses the org.gnome.SettingsDaemon.Power.Screen D-Bus API. Currently
brightness set if the proxy is not ready are ignored; whether the
brightness value should be cached and set once it appears or whether
color profiles should be reapplied is yet to be decided.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
Instead of passing 4 arguments (red, green and blue arrays as well as a
size), always pass them together in a new struct MetaGammaLut. Makes
things slightly less tedious.
The KMS layer still has its own variant, but lets leave it as that for
now, to keep the KMS layer "below" the cross backend CRTC layer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
In practice, for KMS backend CRTC's, we cache the gamma in the monitor
manager instance, so that anyone asking gets the pending or up to date
value, instead of the potentially not up to date value if one queries
after gamma was scheduled to be updated, and before it was actually
updated.
While this is true, lets still move the API to the MetaCrtc type; the
backend specific implementation can still look up cached values from the
MetaMonitorManager, but for users, it becomes less cumbersome to not
have to go via the monitor manager.
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>
This works similiarly to how MetaColorDevice works, by creating them
asynchronously then signalling the 'ready' signal when done. Also
similarly to MetaColorDevice, the on-demand sync cleanup on finalize is
added, to avoid race conditions when hotplugs happens very rapidly,
e.g. in tests.
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>
Ready means it has established the connection to colord and can operate.
Will be used by tests to make sure tests don't fail due to race
conditions when connecting to colord.
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>
Previously, gsd-color handled adding color devices. It got information
about those via the GnomeRR API, which is part of libgnome-desktop.
libgnome-desktop itself got this information from the
org.gnome.Mutter.DisplayConfig.GetResources() D-Bus method, implemented
by mutter.
Now, mutter itself will add all the monitor color devices itself,
without having to go via gsd-color.
We sometimes need to delete colord devices synchronously, in certain
race conditions when we add and remove devices very quickly (e.g. in
tests). However, we cannot use libcolord's 'sync' API variants, as it
has a nested takes-all main loop as a way to invoke the sync call. This
effectively means we end up sometimes not return from this function in a
timely manner, causing wierd issues.
Instead, create our own sync helper, that uses a separate context that
we temporarly push as the thread-default one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
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>
It's not really about monitors, even though it is used for monitors.
Lets shrink MetaMonitorManager a bit moving it to the backend.
While at it, stop leaking it too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
What determines whether one MetaMonitor is the same as the other should
be whether the actual monitor is the same. The way to check this is
comparing the EDID vendor/product/serial fields. Whene these are
incomplete, fall back on the 'winsys ID'.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
Same applies to MetaOutput. The reason for this is to make it possible
to more reliably know when there was EDID telling us about these
details. This will be used for colord integration.
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>
As for the types of monitor, X11 and KMS are currently assumed to always be
physical, while the virtual ones are assumed to be virtual. In theory
X11 ones could be virtual, but lets not bother. KMS ones can be virtual
in the case of virtual KMS, but we typically use that for testing as if
it was physical, so lets leave it as such.
Will later be used to feed correct information to colord.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
Create a color manager type that eventually will be the high level
manager of color related behavior, such as ICC profiles and
color "temperature" a.k.a. night light.
For now, it's only an empty shell. It's also constructed by the actual
backend, as at a later point, the X11 and native color management
implementations will differ.
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>
This reverts an attempt at saving texture memory that was introduced
recently in 16fa2100. It was misguided because the same texture may be
needed in the next frame if a window has multiple previews visible on
screen at once (gnome-shell's overview). Keeping the mipmaps around
seems to reduce the peak render times of the overview by roughly 5%-10%.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2598>
Although its atomic KMS support seems to work at first, mode sets to
anything other than the Xilinx preferred max resolution of 2048x1280
would result in a hang. The xlnx kernel driver is given:
`DRM_MODE_ATOMIC_ALLOW_MODESET | DRM_MODE_PAGE_FLIP_EVENT`
and it does complete the mode set without error, but page flip events
never arrive and so you're frozen on the first frame.
Revert to legacy KMS which has no such problem with non-default modes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2596>
The "activate" and "deactivate" signals on ClutterStage are used by
Cally to track the key-focus when the user is interacting with shell UI.
key-focus only gets tracked while the stage is activated.
Wayland has no concept of the stage receiving focus or not, so right now
the activation state is bound to whether there's a focus_window in
meta_display_sync_wayland_input_focus(). Since display->focus_window is
set pretty much all the time, this effectively binds activation state to
whether the stage holds a grab or not. This is almost good enough, but
it misses cases where key-focus is on the stage without a grab, for
example when keyboard-navigating the panel after using Ctrl+Alt+Tab.
It seems to make more sense to bind the activation state to whether
key-focus is set to an actor or to NULL, so let's do that instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2329>
In the timespan between an activation token being created and the
token being used by the activated application, the surface that started
the activation request may end up destroyed/disposed.
In that case, the token would be left with a stale surface pointer,
maybe causing crashes later on. Set up a destroy notification listener
so that we do know to unset the token surface if that situation arises,
this will result in Mutter not considering the token activatable, thus
maybe issuing the "Application needs attention" notification if the
activated surface did not immediately get focus. In any case this is
better than a compositor crash.
A typical situation where this may happen is "Open With..." dialogs,
since those don't live long after launching the application.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2390
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2592>
There is some surface tracking going on here, and all notify handlers
are possibly leaving the linked wl_listener behind. Ensure it is unlinked
in all destroy notification functions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2588>
Since commit 1bf70334 "tests/runner: Make test runner use the headless
backend", tests are run with the native backend in headless mode, which
will attempt to open each GPU and show a warning (fatal during tests)
if it cannot.
However, in headless mode we might not be logged in on any seat (for
example we might be logged in via ssh instead), which means we might
legitimately not have permission to use any GPUs, even if they exist.
Downgrade the warning to a debug message in this case.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/2381
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2584>
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>
This adds the 4 new connector types that mutter didn't know about from
drm_mode.h in the kernel.
Noticed because mutter kept crashing when plugging in a USB-C adapter to
use an external monitor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2577>
When we e.g. generate switch configs (i.e. the ones from pressing the
Super+P or the switch-config key on laptops), try a bit harder to find a
"good" monitor scale.
With "good", it means pick a scale that was used in a previous
configuration. In practice, this means that if you for example have
configured your external monitor to use a specific scale, then pressed
e.g. "built in only", and then switched back to e.g. "external only" or
"linear", the generated configuration will use the scale that was
previously configured.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
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 will eventually help with better hueristics for finding a good
scale. It currently doesn't change much, but the helper will later gain
more functionality that will also help when coming up with mirroring
configs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
The resulting logical monitor was eventually marked as primary anyway,
but without the config being marked as such, various primary properties
was not set e.g. the one on the MetaOutput. Also, tests would fail.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
This condition is inverted of how it should be. Since pad focus relies
on grouped devices lookups (e.g. pads not grouped with a tablet do not
focus surfaces), this fixes issues in pad focus and event propagation to
wayland clients.
Fixes: fff3654941 - wayland: Check input device capabilities in tablet seats
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2573>
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>
If the window didn't have a size, it would still have a monitor, and
when we are asked to update, we must update, as the old monitor might
not be kept around, leaving us vulnerable to use after free.
Avoid not updating the monitor by using the stored IDs (preferred, or
previous) to find suitable logical monitors, with the primary monitor
being the last fallback unless we're completely headless.
This fixes the assert
!window->monitor ||
g_list_find (meta_monitor_manager_get_logical_monitors (monitor_manager),
window->monitor)
in meta_window_update_for_monitors_changed() being hit when a Wayland
window has been created, but not mapped, when a hotplug happens.
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>
util-private.h includes glib-i18n-lib.h, which requires GETTEXT_PACKAGE
to be defined. The define comes from config.h,
but that cannot be included in headers, so we have to make sure
that any source file that pulls in util-private.h (or a header
that includes it) includes config.h first.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2566>
mutter needs GDK to use the x11 backend. It already calls
gdk_set_allowed_backends ("x11") for this purpose; however, if
GDK_BACKEND=wayland (or any other non-x11 backend possibly) happened to
be in the environment, GDK would fail to initialize at all. This would
result in mutter not registering as X11 window manager, and all X11
clients hanging.
Big thanks to Olivier Fourdan for figuring this out!
v2:
* Restore original value of GDK_BACKEND environment variable after
initializing GDK.
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2022283
Bug: https://bugs.debian.org/1008992
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2496>
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>
