so I have been playing around with Mate lately. I was finally actually able to configure colord on the command line. If you configure colord properly, it is very reliable. But that is of no use because - as I just found out - most apps get their color management info from X atom. And according to my experience, X atom always confuses the profiles sooner or later if you have more than 1 screen.
The most terrible fact is that both important browsers get their color info form X atom too. At least it is possible to set the profile manually in Firefox, but that is really annoying if you switch between screens often.
If you set apps such as Geeqie or RawTherapee to “use system profile”, they will use X atom as well.
What can be done about this?
I know, many of you will say: I have no problem with color management, everything works fine. Well it is definitely perfect with Gnome etc., but what about Mate, Xfce, Kde (etc.)?
Somewhere I read that colord-kde works fine with multiple screens in Arch/Manjaro. But I think I tested it some weeks or months ago and it did not. And then there is also Oyranos…
You know, I am getting really furious! It just still does not work properly! I mean, it is actually unbelievable! Actually it works, but no app uses the working solution! wt*
Using the X atom is the right way to do this, since it is operating system independent - it will work wherever X works, even remotely. To work on more than the first screen, both the program that sets the X atom and the application that uses the profile have to follow the same convention. For systems that use XRandR, the per output _ICC_PROFILE atom should used. As a fallback, the root atom should be used, by following this naming convention. If you are finding that this isn’t working, then figure out whether it is the setter and/or the application that is not following this convention, and contact the relevant developers to get it fixed.
(Note that ArgyllCMS’s dispwin follows this convention, and can be used to set both the XRandR output and X root atom.)
Thanks for the answer, will try dispwin
However I read in the Arch documentation that dispwin does not work with more than 1 screen
https://wiki.archlinux.org/index.php/ICC_profiles#dispwin
And, another question: what is the Gnome color manager actually doing? I think it uses colord, but it also configures x atom correctly
And I also want to add that, although I am really not an expert in this area or computer scientist, it seems to me that it is debatable if colord or x atom is better.
I’ve carefully tested that dispwin works in setting the correct atoms for multi-monitor setup, so I’m pretty confident it’s right. I have no control over whether applications correctly make use of this though.
Since they are both part of gnome, I expect so, but I don’t know for sure what they are doing - you’d have to ask Richard Hughes about it, or figure it out by experiment.
[ Initially dispwin worked with colord in setting profiles, but unfortunately it got broken at some stage, and Richard doesn’t seem to have been able to fix it, so by default dispwin uses its own method of saving display profile state. ]
how do I specify for which display dispwin should set the profile?
so far I tried “dispwin -I [profile/path]” + “1” or “0”, but the numbers were really just guessing
it just set the profile for the first display no matter which number I chose, and it seems to work without number as well
however, it does not appear to work without the argument -I like it is suggested in the Arch documentation
Ok, I think I got somewhere here, but it is not working.
I switched on both screens, I set the profile with dispwin for both screens, using “-d1” and “-d2”. But then I switched off the external screen, so the internal screen became screen nr1, and it had the wrong profile
I checked with darktable-cmstest
I mean if I set the profiles for both screens, internal is 1, external is 2, and switch off the internal, the external becomes nr 1 and gets the profile for the internal which is wrong.
It works as long as you do not switch around
I am thinking about “dispwin -D” and “ARGYLL_USE_COLORD”
I think I have got it!!! Color management apprears to be working well with MATE and 2 screens. Details will follow. I hope it is really working. Looks like it so far.
Short version of the “tutorial”:
-
configure colord in the command line properly
-
set up the following commands as startup apps
export ARGYLL_USE_COLORD=yes
dispwin -X
well and maybe disable the Displaycal Profile Loader
well, apparently, dispwin can set the profile for colord as well. export ARGYLL_USE_COLORD=yes does not appear to be necessary, but dispwin -X makes the picture “shake” when scrolling. but the “shaking” occurs with other desktop environments, too.
Both colord and ArgyllCMS dispwin use the display EDID to identify the display and load the appropriate profile, so assuming EDID is available for your displays, the profile should follow it no mater which out put it is plugged into. I would suspect that most applications aren’t aware of dynamic display changes, and will need restarting.
The drawback of dispwin is that it is a “one shot” utility not a daemon, and doesn’t get notified of when a display gets detached or plugged in, and so the “dispwin -D” is a crude workaround (constantly running and polling the displays).
I did a little looking about on a Ubuntu 18.04 system I’ve just setup, and it seems like ARGYLL_USE_COLORD doesn’t work on it because the necessary colord libcolordcompat.so library is not installed on the system.
The other bad news is that it seems that colord does not set the atom on the xrandr crtc, which is rather a pity, since this is likely to be much more reliable for multi-monitor than using a root atom naming convention. I guess that means that none of the applications use it either 
In theory one could use udev to trigger dispwin to load the installed icc profiles (making use of the ucmm way of storing this, rather than colord.) There would have to be some sort of udev entry callout to a script that invokes dispwin, and making sure that dispwin is involked in the correct sort of environment (i.e. DISPLAY is set correctly and that it has authority to open the X server.)
Well since the vertical “shaking” while scrolling occurs on Gnome-based systems as well, my guess is that the dispwin daemon is active there, too. But probably the shaking has something to do with my internal weak Intel video card. I am about to have a look at Kde.
Anyway, I think it would be much better for me if the apps could use the CM info provided by colord since that might not produce any shaking.
BTW: If I deactivate CM and set the profile manually in Firefox, there is no shaking.
edit: Kde is the same with dispwin -X as other DEs (shaking); in Cinnamon though scrolling is almost 100% smooth - apparently dispwin -X is not active.
I would suspect that any “shaking” is simply the X server being busy when dispwin checks to see if any of the outputs have changed.
I’m not sure what you mean by that. Nothing runs dispwin except you, the user. Or do you mean that you set dispwin -X running, and that under Cinnamon it is not setting the calibration and atoms ?
If so, are you sure you aren’t switching to using Wayland at the same time ?
I just meant that first I suspected that dispwin -X was active on Gnome-based systems where color is managed by the Gnome Color Manager but I checked and it is not the case (I checked the processes).
I really wonder whether the shaking (only while scrolling) is present on “stronger” computers with a real video card, but at the moment I have no way to test this. If not, dispwin -X would be a good way to manage color.
Anyway, as far as I can see (being no expert/programmer/it pro), colord would be the better way to manage color on Linux/x11. But I have noticed that much is going on with Wayland these days.
I think I did not try Wayland yet.
Wayland doesn’t support color management.