It appears that Kwin sets the profile of the root window (X atom always to sRGB even if color correction is enabled. I found this by elimination after fiddling with oyranos for hours and not being able to figure out how to fix this problem. I used darktable a RAW photo processing tool that has a tester for color profiles and checks the X atom profile for applications that do not understand color management and colord color space. An output from it while using compiz as window manages is below followed by the output form the same tool wild running kwin. Nothing was changed in between switching from kwin to compiz and back. 1) With Compiz ------------------- $ darktable-cmstest darktable-cmstest version 1.7.0+24~g7735bc3 this executable was built with colord support enabled darktable itself was built with colord support enabled DP-1 the X atom and colord returned the same profile X atom: _ICC_PROFILE (515648 bytes) description: PA279 2013-10-19 2231 2.2 HQ XYZLUT+MTX colord: "/home/bogdan/.local/share/icc/PA279 2013-10-19 2231 2.2 HQ XYZLUT+MTX.icc" description: PA279 2013-10-19 2231 2.2 HQ XYZLUT+MTX Your system seems to be correctly configured 2) with Kwin -------------- $darktable-cmstest version 1.7.0+24~g7735bc3 this executable was built with colord support enabled darktable itself was built with colord support enabled DP-1 the X atom and colord returned different profiles X atom: _ICC_PROFILE (10512 bytes) description: sRGB colord: "/home/bogdan/.local/share/icc/PA279 2013-10-19 2231 2.2 HQ XYZLUT+MTX.icc" description: PA279 2013-10-19 2231 2.2 HQ XYZLUT+MTX Better check your system setup - some monitors reported different profiles Reproducible: Always Steps to Reproduce: 1. query the x atom and colord profiles with what tool you like 2. switch to compiz 3. logout 4. log back in 5. rerun the color space queries as in point 1 6,. compare results Actual Results: x atom and colord profiles differ for kwin while they are the same for compiz (after re-loging in) Expected Results: have both profiles pointing to the same color space
> even if color correction is enabled FTR: _ICC_PROFILE isn't set on my root window and I don't see the property in the kwin code at all. lxr.kde.org suggests that colord-kded/ColorD.cpp would set it. I assume you've the colorcorrection enabled, the colorcorrection talks to colord-kde and that adjusts the setting? Can you see what happens when you disable color correction and logout/login (to get a clean state)?
could you please answer the questions from comment #1?
Since then I upgraded to Suse 13.2 and the problems does not exist anymore. It is hard to figure out what had caused the behaviour other thant the newer kwin and/or different X setup of the xroot though a newer colord-kde in Suse 13.2 compared to 13.1. No I am getting the same results with compiz and kwin. I changed the status to works for me although I am not sure why. I think the bug can be closed since we don't know what produced it an I can't reproduce it anymore.
After further investigation done after it happened again it appears that the problem was triggered by a combinations of factor 1) at oyranos level, which can't handle special characters such as ^ in the file name. Oyranos has actually some bugs that are transferred to the KDE client which uses oyranos 2) setting the QT to native in the System Settings. With QT rendering on raster the X root is always set to sRGB The color management in KDE is still young and there are many redundancies I don't understand where the kolorserver is looking for icc profiles there are so many /var/lib/color /usr/share/color/icc and a few other subdirectories display but also Display and ~/.local/share/color/icc Too many places and too confusing it it is a standard place it should be organized as such.
This bug has had its resolution changed, but accidentally has been left in NEEDSINFO status. I am thus closing this bug and setting the status as RESOLVED to reflect the resolution change.
(In reply to Andrew Crouthamel from comment #5) [...] > RESOLVED to reflect the resolution change. Which is?
KWin from Plasma 5 doesn't have color correction yet. If/when that feature arrives, we will be able to check bug reports, including this one. I suggest to re-open it, if the issue persists then.