#3008 (Bug) Desktop file conflicts with gnome-color-manager
+1 0
Closed as Works For Me
Component: DisplayCAL | Milestone: 3.1
Created by Jehan Pages
Last modified
Version: dispcalGUI-3.0.4.0-68.1.x86_64
I have not tried more recent version, in particular not the latest 3.1.3.1 version (renamed DisplayCal). Sorry.
== Problem ==
your package installs a desktop file, autostarted with the system: /etc/xdg/autostart/z-dispcalGUI-apply-profiles.desktop
After installing dispcalGUI/DisplayCal, my ICC profile failed to be applied at startup. Sometimes I could see it applied for a split of a second before getting disabled again. Very very rarely (like once every several dozens startup?), it would be successfully applied and stay so. But most of the time, I had to manually reapply the profile, at each and every startup! Extremely bothersome.
See my bug report on GNOME bugzilla, before I realized that the problem was not with GNOME (thanks to Richard Hughes actually who found the source of the issue): https://bugzilla.gnome.org/show_bug.cgi?id=756862
In any case, it turns out that your desktop file was running `dispcalGUI-apply-profiles`, which was actually “un-applying” the profile that GNOME color manager already applied. So there was some race condition, and I guess that DisplayCal desktop file was run last, which explains why it nearly always “won” (is it why the desktop file’s name starts with ‘z-‘? To run last? Assuming alphabetical order is used)
Could DisplayCal not install the desktop file in autostart, or else could dispcalGUI-apply-profiles not undo the color profile which have already been applied by the desktop?
dispcalGUI-apply-profiles (text/plain | 2016-05-16 13:53:06)
Hi,
Please attach a log (complete output) of dispcalGUI-apply-profiles, thanks.
The order of execution is not guaranteed AFAIK, the “z-” prefix is just to make it more likely that it is the last to run (although a specific order of execution is not required for proper operation) because it’s not as essential to run early as other autostart entries that users rely on may be.
You can safely remove the desktop file as a work-around to the problem until a fix is availble, or de-select “Load calibration on startup” when installing a profile in dispcalGUI, which will put the loader in “bypass” (do nothing) mode.
Attached. There are warning/errors. Also I can definitely confirm that each time I run it, it just unset my current profile applied on the screen.
This is what I already did for the time being. And that’s good enough a workaround for me indeed. But then if it can be fixed upstream, that’s ideal! 🙂
Check with `colormgr get-devices-by-kind display` if the device has an assigned profile. Also, as Richard has pointed out in the Gnome bug report, there may be an underlying issue with the session daemon.
Clearing the calibration before loading the profile is only a problem because there is no profile assigned, and thus nothing to load. Note that recent versions of DisplayCAL (since 3.1) no longer clear the calibration before loading the profile.
I see several profiles here but I can’t see which one is supposed to be assigned in this output. In GNOME color manager though, the one labelled “Profile 1” above is the one assigned.
Maybe. But for full story, I had the problem also on a brand newly installed Fedora 23 with GNOME on another computer. So either this session daemon issue is nearly an out-of-the-box bug, or whatever was showing in my logs were not relevant to the issue. Also something which does not show up in the GNOME bug report is that I actually met Richard in person at LGM 16, and this is when he actually diagnosed the issue directly on my computer.
Ok. But do GNOME and DisplayCal set differently the “assigned profile”? Because in the GNOME GUI, this display definitely has a profile assigned (and the colors are definitely different, my display is very bluish by default, so GNOME did load the profile). So how is it that it does not show as assigned for other programs? Does GNOME do something non-standard here?
You can get the current default profile with `colormgr device-get-default-profile xrandr-LVDS1`. Still, something seems off, if xrandr_LVDS27_gdm_42 (with no profile assigned) is the active device on login (when the XDG autostart entries are run), why did it suddenly change to xrandr_LVDS1_jehan_1000? Are there several display devices connected to the PC (but I assume this is a Laptop)?
Similar hardware, especially graphics-related? I can’t reproduce the issue in my Fedora 23 VM.
No. DisplayCAL-apply-profiles checks if a profile is assigned in GCM. So, on a correctly working system with colord and gnome-color-manager, DisplayCAL-apply-profiles should not affect the current calibration. The issue in your case arose because you were using an older version of dispcalGUI, and there seems to be something weird going on with the display devices that colord (or rather, the session daemon?) sees.
It’s a laptop indeed. There are usually no other display device than the default screen, though sometimes I plug another screen of course. Nevertheless this issue happens all the time (whereas there is 1 screen or more plugged at login)
Nope the other is a desktop computer, with a Nvidia card (and proprietary driver) whereas my laptop has integrated Intel graphics.
Ok. As the side-effect (clearing the calibration before loading the profile) is no longer the case since 3.1, I’ll mark this as resolved.
I still consider the display device ID that colord sees changing seemingly on a whim after login to be a problem, but that seems to be related to something in colord or Gnome session.