Red Hat Bugzilla – Bug 847421
Color calibration profiles are not automatically applied to monitors
Last modified: 2013-02-17 16:17:15 EST
Description of problem:
When I boot my machine, the monitor comes up with the default profile, not my calibrated one. When I plug in a second external monitor, I also have to reset the profile, and each time I unplug/replug it.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Generate color profiles
2.Select them in Color settings
Monitors are using default/no calibration
Should use calibrated color profiles
Lenovo X220 with external Display Port Samsung monitor. Profiles generated from gnome-color-manager with a Huey Pro.
I'm also seeing this issue. I have to go back in to the color settings panel every time I log into Gnome and re-import my profiles.
I've also filed a bug for this upstream:
Yep, still happening in F18.
I'm pretty sure this was fixed in 0.1.29 -- can you try with the packages here please: https://admin.fedoraproject.org/updates/FEDORA-2013-2053/
(In reply to comment #4)
> I'm pretty sure this was fixed in 0.1.29 -- can you try with the packages
> here please: https://admin.fedoraproject.org/updates/FEDORA-2013-2053/
No, the problem remains with colord-0.1.29-1.fc18 installed.
Did you (In reply to comment #5)
> No, the problem remains with colord-0.1.29-1.fc18 installed.
Did you reboot? If so, can you attach your /var/lib/colord/mapping.db please. Thanks.
Created attachment 697985 [details]
I did reboot after the update. Here's the mapping.db.
That's very odd. That database is the pre-0.1.29 schema. Can you attach the output of:
sudo killall colord
sudo /usr/libexec/colord --verbose
and in another tab
Please attach the whole colord log. Thanks.
Created attachment 698429 [details]
colord log file
colord log file. I also added a profile to my laptop screen as the last thing.
I really don't understand what's going on... Can you please do:
> SELECT * FROM mappings_v2 LIMIT 1;
The last line should produce an error, but I really don't know how color 0.1.29 started without creating the new mappings database. The only thing left to try is:
ls -l /var/lib/colord/mapping.db
which should produce colord:colord as the user and group. I'm guessing yours will say something else... If so, can you please try this colord build please: http://people.freedesktop.org/~hughsient/fedora/18/x86_64/ -- thanks.
(In reply to comment #10)
> I really don't understand what's going on... Can you please do:
> sqlite /var/lib/colord/mapping.db
> > .d
> > SELECT * FROM mappings_v2 LIMIT 1;
> > .q
> The last line should produce an error, but I really don't know how color
> 0.1.29 started without creating the new mappings database.
Well, it didn't have the mappings_v2 when I sent it, but it seems to have acquired one since:
: saboo:pts/4; sqlite3 /var/lib/colord/mapping.db
SQLite version 3.7.13 2012-06-11 02:05:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> select * FROM mappings_v2 LIMIT 1;
1338169575920722|xrandr-Samsung Electric Company-SyncMaster-1497646899|icc-61b17dc103736f36d08ed3b2952bc3d2-jeremy
> The only thing
> left to try is:
> ls -l /var/lib/colord/mapping.db
-rw-r--r--. 1 root root 5120 Feb 17 11:02 /var/lib/colord/mapping.db
Are these legacy perms left over from some old version of Fedora/colord?
> which should produce colord:colord as the user and group. I'm guessing yours
> will say something else... If so, can you please try this colord build
> please: http://people.freedesktop.org/~hughsient/fedora/18/x86_64/ -- thanks.
OK, I'll do that rather than chowning it. Hm, unfortunately I'm getting conflicts with those packages ("requires libdtp94-private.so.0 libhuey-private.so.0"), and colord-libs conflicts with the i686 install, and I'd rather not remove all that at the moment.
So because of the package problems I ended up chowning -R colord.colord /var/lib/colord, and after restart its now its all working as expected.
*** This bug has been marked as a duplicate of bug 909580 ***