As implemented in colord 1.4.6, cd_icc_load_handle() has three possible
results:
1. success, taking ownership of the profile;
2. failure because cmsGetProfileContextID returns NULL, *not* taking
ownership of the profile;
3. failure in cd_icc_load(), taking ownership of the profile.
The previous commit ensures that we are not in case 2.
In case 3 where cd_icc_load() fails, ownership was already given to
the colord CdIcc object, so it will be freed when the g_autoptr unrefs
the CdIcc, and we must not free it again: that would be a double-free,
potentially resulting in memory corruption.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/2659
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2877>
Writing to fields (in this case the MetaColorDevice::pending_state) in
response to an asynchronous operation that was cancelled means we'll
write to an arbitrary memory location, potentially causing segmentation
faults or memory corruption.
Avoid these segfaults or memory corruption by only updating state if we
weren't cancelled. Also avoid trying to dereference the device pointer
if we're cancelled.
The memory corruption due to this has been causing test flakyness in the
monitor unit tests due, which should now hopefully be fixed.
Fixes: 19837796fe
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2794>
This just checks for any chromaticity being zero and gamma being in
range but we could do a better job at detecting bad data in the future.
Also check the return value of cmsCreateRGBProfileTHR which can be NULL.
Fixes gnome-shell#5875
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2627>
We might fail with some part of the color profile construction and
initialization. For example there might be a system wide profile with
the same ID as one we attempt to add from a local ICC directory. When
this happens, we should drop these profiles, and use the ones from the
system instead.
Profiles may fail to initialize for other reasons too, e.g.
unpredictable colord errors, or other I/O issues.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2429
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2622>
This is instead of getting anything from the CdDevice. This avoids a
crash when CdDevice isn't successfully setup but something still tries
to look up the filename of the ICC profile.
This isn't a real bug fix for anything, but there is no reason having to
rely on CdDevice for this anyway, and as we don't really have control of
it, it's less reliable of containing something valid.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2622>
If the vendor_name was previously successfully determined, we would end
up in the else case, overwriting it with "Unknown vendor" and leaking
the previous vendor_name.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2603>
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>
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>
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>
