Bug 847421

Summary: Color calibration profiles are not automatically applied to monitors
Product: [Fedora] Fedora Reporter: Jeremy Fitzhardinge <jeremy>
Component: gnome-color-managerAssignee: Richard Hughes <hughsient>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 18CC: fedora, hughsient, rhughes
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-17 21:17:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
/var/lib/colord/mapping.db
none
colord log file none

Description Jeremy Fitzhardinge 2012-08-11 01:25:42 UTC 
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):
gnome-color-manager-3.4.2-1.fc17.x86_64

How reproducible:
Always

Steps to Reproduce:
1.Generate color profiles
2.Select them in Color settings
3.Reboot
  
Actual results:
Monitors are using default/no calibration

Expected results:
Should use calibrated color profiles

Additional info:
Lenovo X220 with external Display Port Samsung monitor.  Profiles generated from gnome-color-manager with a Huey Pro.
Comment 1 Russell Harrison 2012-11-10 22:53:26 UTC 
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.
Comment 2 Russell Harrison 2013-02-14 22:52:41 UTC 
I've also filed a bug for this upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=693846
Comment 3 Jeremy Fitzhardinge 2013-02-14 23:08:19 UTC 
Yep, still happening in F18.
Comment 4 Richard Hughes 2013-02-15 14:40:13 UTC 
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/
Comment 5 Jeremy Fitzhardinge 2013-02-15 18:42:16 UTC 
(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.
Comment 6 Richard Hughes 2013-02-15 19:21:01 UTC 
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.
Comment 7 Jeremy Fitzhardinge 2013-02-15 22:28:14 UTC 
Created attachment 697985 [details]
/var/lib/colord/mapping.db

I did reboot after the update.  Here's the mapping.db.
Comment 8 Richard Hughes 2013-02-16 08:47:29 UTC 
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

killall gnome-settings-daemon

Please attach the whole colord log. Thanks.
Comment 9 Jeremy Fitzhardinge 2013-02-17 05:39:40 UTC 
Created attachment 698429 [details]
colord log file

colord log file.  I also added a profile to my laptop screen as the last thing.
Comment 10 Richard Hughes 2013-02-17 20:06:01 UTC 
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. 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.
Comment 11 Jeremy Fitzhardinge 2013-02-17 20:33:38 UTC 
(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
sqlite> 


> 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.
Comment 12 Jeremy Fitzhardinge 2013-02-17 20:43:47 UTC 
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.
Comment 13 Richard Hughes 2013-02-17 21:17:15 UTC 

*** This bug has been marked as a duplicate of bug 909580 ***