Am 27.11.2014 um 15:58 schrieb Niels Ole Salscheider: >>>>> #define WL_HIDE_DEPRECATED >>>>> #include <wayland-server.h> >>>>> >>>>> @@ -40,6 +41,10 @@ extern "C" { >>>>> >>>>> #include "config-parser.h" >>>>> #include "zalloc.h" >>>>> >>>>> +#ifdef HAVE_LCMS >>>>> +#include <lcms2.h> >>>>> +#endif >>>>> + >>>>> >>>>> #ifndef MIN >>>>> #define MIN(x,y) (((x) < (y)) ? (x) : (y)) >>>>> #endif >>>>> >>>>> @@ -179,6 +184,24 @@ enum weston_mode_switch_op { >>>>> >>>>> WESTON_MODE_SWITCH_RESTORE_NATIVE >>>>> >>>>> }; >>>>> >>>>> +struct weston_clut { >>>>> + unsigned points; >>>>> + char *data; >>>>> +}; >>>>> + >>>>> +struct weston_colorspace { >>>>> +#ifdef HAVE_LCMS >>>>> + cmsHPROFILE lcms_handle; >>>>> +#endif >>>>> + struct weston_clut clut; >>>>> + >>>>> + int destroyable; >>>>> + int refcount; >>>>> + int input; >>>>> + >>>>> + struct weston_compositor *compositor; >>>>> +}; >> Note, that compositor.h is a public, installed header. You cannot use >> HAVE_LCMS, because any external project using this header would then >> receive the definition based on its own configuration, not how the >> Weston that is already installed was configured.
Agreed, lcms internals are not nice to get exposed at this level. Generally speaking, lcms provides a great API for a CMM. On the other side, lcms is just one CMM and people in the open source world decided many times to define and implement different API's. E.g. ArgyllCMS (features, speed), SampleICC (spec playground) and Mozilla/Chrome with qcms (secuirity, speed). So it is not wise to stick to especially one CMM, be it lcms or whatever. A CMM module can register its own functions for their handle type. You could either wrap the CMM functions or use initial dummy functions instead for function pointers. The type of the handle is not really needed to get exposed. As long as the CMM registers its API at startup, that procedure is simple. A different approach is to store the data blob of the profile. The lcms expanded profile handle needs certainly more memory, than the plain memory block. And loading the profile on the fly is really fast. You need the CMM profile handle mostly in the weston_build_clut() function and for the header ID computation in other places. So profile memory blob and profile header ID would suffice? Then following might work out for the later approach: +struct weston_colorspace { + + void * profile_data; + int profile_data_size; + unsigned char profile_id[16]; + + struct weston_clut clut; + + int destroyable; + int refcount; + int input; + + struct weston_compositor *compositor; +}; This opens the path to exchange the CMM without much fuzz on start time depending on the system requirements. Thanks Kai-Uwe _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel