[colord] xiccd - a daemon to apply display ICC profiles without Gnome/KDE

Alexey Galakhov agalakhov at gmail.com
Wed Jul 3 02:12:19 PDT 2013


On 07/03/2013 02:43 PM, Richard Hughes wrote:

> I did wonder about a CdIccDir type object that just had something like
> GPtrArray* cd_icc_dir_get_all() and ::removed(CdIcc) and
> ::added(CdIcc) although I didn't know if parsing each file
> unconditionally was what we wanted to do. Certainly if we're doing
> basically the same thing in gnome-settings-daemon and xiccd then it
> makes sense to share code as it's not exactly trivial.

Yes, and it is not exactly the same. Like colord-kde, xiccd watches the
directory for new files. Every valid ICC profile is added immediately.

My implementation of ICC storage looks like your CdIccDir object. Basic
operations are similar to ::added, ::removed and
cd_icc_create_FILE_from_edid which generates correct file path based on
EDID checksum.

Oh, I forgot. Please add cd_icc_save_data() so that an CdIcc object
could be converted to _ICC_PROFILE property without direct file access.
Then the client will be able to work with profiles without reading files
at all.

>> I think about splitting xiccd in two separate parts in the future. One
>> for file handling only and one for XRandR only. Or maybe just command
>> line options for that.
> 
> Right. In a wayland world (using the weston compositor) we want only
> the profile side to work, and *not* the xrandr stuff (as it's handled
> by the compositor). As part of porting g-s-d to wayland I'll be
> splitting the profile/xrandr parts and so I think this is a really
> good idea if you do the same.

Sure. xiccd is meant to be something like stub for thise who doesn't
have native support yet. I'll try also to make it like a "reference
implementation" for those who wants to write native support.

Alex


More information about the colord mailing list