Bug 439135 - Color management on Wayland
Summary: Color management on Wayland
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: 5.22.2
Platform: Arch Linux Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL: https://gitlab.freedesktop.org/waylan...
Keywords: wayland
Depends on:
Blocks:
 
Reported: 2021-06-25 01:06 UTC by amspacey
Modified: 2023-12-12 10:55 UTC (History)
27 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description amspacey 2021-06-25 01:06:10 UTC
SUMMARY

A discussion with a KDE contributor on Reddit revealed that color management is apparently supposed to be working as of 5.22 under the KWin Wayland compositor. It mostly works for me in Gnome, but doesn't work at all in KDE.


STEPS TO REPRODUCE
1. Start a Wayland session (startplasma-wayland)
2. Observe whether color corrections previously applied under X are applied
3. Open settings and go to color corrections
4. Try to apply the ICC profile for the screen
5. Try to use colormgr to manually import / apply an ICC profile


OBSERVED RESULT

No color corrections can be applied under KWin. None of the profiles shown under X show up under Wayland, probably because the device ID is different. Trying to import any profile (including profiles that were *not* installed under X) gives the error "color profile is already installed". 

Trying to import a profile with colormgr hangs for a few seconds and then returns "the profile was not added in time". 

I *can* apply certain test profiles built into colord to the screen, oddly enough. E.g. there's a profile called Bluish.icc that changes the white point of the screen to make it much bluer, for testing purposes. I can apply this profile with colord-kde and it does in fact make my screen much bluer. I was able to delete this profile with colormgr, and after doing that I can't import it again (I get the errors described above). So it's possible this issue is just with *importing* profiles.

Under Gnome, the monitor is correctly detected (although once again without any profiles because of a differing device ID) and I can import and apply my profiles, which works as expected. The calibration curves are correctly loaded in the VCGT under Gnome. Some applications that were previously color managed under KWin + X are *not* correctly color managed under Gnome. Although the white balance has been corrected due to the system-wide colord settings, sRGB images are much too saturated. These applications include Firefox and eog (eye of gnome). Most applications that allow manually setting a profile (versus relying on the application communicating with colord) work correctly, e.g. GIMP.


EXPECTED RESULT

Color management should work as expected. colord-kde should correctly detect my screen and allow me to apply profiles, and colord should load the calibration curves into the VCGT when I do so. 

Also, because the Wayland protocol for communicating color management information between applications and the compositor is not yet finalized or merged (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14), applications running on a color managed KDE + Wayland system are expected to do their own color management at this time. Firefox (running under xwayland for me) should be able to request the active color profile from colord, and send correctly mapped colors for my screen to the compositor. Same with eog and so on.


SOFTWARE/OS VERSIONS
Linux: Arch Linux / kernel 5.12.12 / x86_64
KDE Plasma Version: 5.22.2
KDE Frameworks Version: 5.83.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
Graphics: Mesa DRI Intel HD Graphics 3000

Please let me know if there's more information I can provide. I'm able to test stuff and provide additional debugging information as needed.
Comment 1 amspacey 2021-06-25 01:13:32 UTC
Also, this is kind of a nit that I didn't want to make a whole separate bug report for, but would you consider adding a manual override for the manufacturer name of my monitor? You're relying on the PNP ID list, which on my distro is provided by the hwids package.

For some insane inscrutable reason, the name of the company that made my monitor is literally "DO NOT USE - AUO" according to the UEFI PNP ID registry: https://uefi.org/PNP_ID_List?search=AUO

I realize it's kind of ugly, but a two line fix, something like

    if (pnpid == "AUO")
        return "AU Optronics";

would fix this issue for me a probably a lot of users. It's ugly to see "DO NOT USE - AUO" as the name of the screen in colord-kde.
Comment 2 Nate Graham 2021-07-30 15:55:09 UTC
Yeah. Added to https://community.kde.org/Plasma/Wayland_Showstoppers for tracking purposes.
Comment 3 tempel.julian 2021-11-02 14:07:32 UTC
Not sure if I should post here or report a new bug, but the issue might simply be that Plasma doesn't start colord.

I've managed to make my ICM profile usable inside Plasma Wayland session by adding it on Xorg via the color correction KCM and clicking the "install sytem wide" box. Then I could finally select it from the dropdown list on Wayland and indeed correction via GPU gamma ramps is applied.

However, when restarting, gamma ramps aren't applied automatically when logging in. I need to open the color correction KCM page, only then colord process is started and 1D LUT applied. Alternatively, colord can also be launched ("start") via systemd.

So, I think a lot of trouble might come from the fact that the Wayland (and also Xorg?) session doesn't start colord reliably. It's a service that can't be put in autostart ("enable") via systemd, the desktop environment is expected to start it.
Comment 4 James Graham 2021-12-27 09:42:58 UTC
I was setting up colour profiles for my new monitor yesterday and I got it working on Wayland however there are numerous UX issues that made it a lot of work. I can confirm the issues found in the original post (only seeing the default profiles but not being able to import new ones) but after some digging found workarounds that eventually allowed me to get an ICC profile for my monitor loaded.

So initially when I tried to load the profile I had I would get an error saying it couldn't copy the profile. After digging and finding the command for the ICC profile importer (colord-kde-icc-importer) and running it in terminal I found that it was trying to copy the file to a location that didn't exist (~/.local/share/icc). By creating this location the importer would work and copy the file to the location. 

This probably means that the importer needs to be able to create the location if it doesn't already exist. However this doesn't solve the issue as even when I was able to get the importer to work the profile would not appear in the colour corrections tab. It seems this is due to the fact that it doesn't look at the user location for profiles. When I copied the profile manually to /usr/share/color/icc/ it appeared instantly and I was able to apply it.

TLDR: It seems everything works its just that all the UI is not hooked up to allow importing profiles to a user location and applying them from there. A workaround for now seems to be to copy the profile to /usr/share/color/icc (or wherever colord is putting it's default profiles on your machine) and then you can use them just fine.
Comment 5 tempel.julian 2022-04-26 22:55:32 UTC
Any news on this? James likely has pinned down what's the issue, sounds to my layman ears like a fix should be doable.
This can be a major hassle to users who want to use the Plasma Wayland session and it's unfortunate that the functioning core feature (applying VCGT of an ICC profile) is foiled by something that mostly seems to be a UI issue.
Comment 6 tempel.julian 2022-05-19 00:31:15 UTC
I can confirm that profiles need to be added to global system path ("/usr/share/color/icc/colord" on Arch) to be able to add the ICC profile from the dropdown menu in color correction KCM. However, this still isn't sufficient in my case to make it apply the ICC profile's VCGT automatically after log-in. VCGT correction only gets loaded after log-in when I manually open the color correction KCM page or when I restart colord via systemd.
Comment 7 Störm Poorun 2022-06-13 09:45:58 UTC
See also:

https://invent.kde.org/plasma/kwin/-/issues/11
Comment 8 Bug Janitor Service 2023-10-04 17:26:14 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4471
Comment 9 Zamundaaa 2023-10-25 13:55:21 UTC
Git commit 8d25550c2208b19c3cb2de46364a9bbc9678487e by Xaver Hugl.
Committed on 25/10/2023 at 15:34.
Pushed by zamundaaa into branch 'master'.

backends/drm: support applying icc profiles with color management

While applications are still restricted to sRGB, this allows working on sRGB
content on displays with a wide color gamut as the whole profile gets applied,
instead of just the VCGT.

M  +1    -0    autotests/drm/CMakeLists.txt
M  +2    -0    src/backends/drm/CMakeLists.txt
M  +2    -1    src/backends/drm/drm_egl_cursor_layer.cpp
M  +3    -2    src/backends/drm/drm_egl_layer.cpp
M  +31   -12   src/backends/drm/drm_egl_layer_surface.cpp
M  +15   -7    src/backends/drm/drm_egl_layer_surface.h
M  +3    -5    src/backends/drm/drm_output.cpp
M  +29   -19   src/backends/drm/drm_pipeline.cpp
M  +5    -4    src/backends/drm/drm_pipeline.h
A  +56   -0    src/backends/drm/icc.frag
A  +6    -0    src/backends/drm/icc.qrc
A  +59   -0    src/backends/drm/icc_core.frag
A  +207  -0    src/backends/drm/icc_shader.cpp     [License: GPL(v2.0+)]
A  +60   -0    src/backends/drm/icc_shader.h     [License: GPL(v2.0+)]
M  +8    -0    src/libkwineffects/glshader.cpp
M  +1    -0    src/libkwineffects/glshader.h

https://invent.kde.org/plasma/kwin/-/commit/8d25550c2208b19c3cb2de46364a9bbc9678487e
Comment 10 Zamundaaa 2023-12-12 10:55:30 UTC
As ICC profiles are now properly supported, I'm closing this now. You can follow https://invent.kde.org/plasma/kwin/-/issues/11 for support of various protocols etc around color management instead of this