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>
I don't see how this makes sense at all, ClutterClickAction really
shouldn't mess with BUTTON_RELEASE events that are not part of a
gesture.
So propagate those events instead of stopping them.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2552>
The source field was removed from ClutterEvent with commit
b644ea1bce because the preferred way of
getting the event actor is now to use the device/sequence actor from the
stage directly.
With crossing events it's not that easy though, as crossing events
explicitly have a source and related actor that doesn't have to be the
same actor as the device actor. Since we kept around the "related" field
there anyway, let's also introduce a "source" field in
ClutterCrossingEvent and return that actor when get_source() is called
on a crossing event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2551>
Just like we did with the ::captured-event signal, add detail to the
::event signal too. At the first glance this might not seem necessary
since there are individual signals like scroll-event or touch-event that
get emitted at the same time, but these don't exist for touchpad gesture
events and others.
As an easy solution for that, just make it possible to use detail on the
event signal as we did with the caputured-event signal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2431>
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>
