The weston_color_manager struct could lose the state field. The CMS plugins allocates it and can add state as needed. You should move the weston_cms_output_added call below weston_output_init (which initializes the compositor pointer in the outputs) and drop the first argument from output_added, output_removed, weston_cms_output_added and weston_cms_output_removed.
You should make a function which calls set_color_profile in weston instead of calling it directly from the plugins. weston may want to do some non-backend specific processing (such as informing the renderer of the new profile). color_profile has to move from drm_output to weston_output. The struct weston_color_profile * argument can then be dropped from set_color_profile. Perhaps you should rename set_color_profile to updated_color_profile. You should also move the appropriate code from drm_output_set_color_profile into this function. It should be called by the drm backend when using a hardcoded profile. Also allow set_color_profile to be null, which is the case for most backends. I think struct weston_color_profile should also be created in this function with filename and lcms_handle passed as arguments. The CMS plugin should pass ownership of the lcms_handle to weston. I don't see a GLib event loop, so I'm curious to how the signals work. On Wed, Apr 3, 2013 at 9:47 PM, Richard Hughes <[email protected]> wrote: > I've attached three patches for comments and review. I'm a GLib > programmer at heart, so please be kind if I've made huge obvious > architectural mistakes :) > > Patch 1 adds the framework code, patch 2 adds the ability to load CMS > modules, and patch 3 adds a CMS module written for colord. With those > three patches it actually works, and you can change the applied > profile at runtime using gnome-color-manager or colord-kde. Note, this > patchset just aims to set the calibration state, but I have left the > lcms hProfile handle available for when we want to construct 3d > shaders for the sub-surface color correction. I've also used all the > new features in colord 0.1.32, but say if you need/want me to tone > this down to something Ubuntu/whatever is shipping. > > I've left a wodge of documentation in src/cms.h explaining all the > terms and the general idea on how I think this should work. There are > a ton of FIXMEs in relation to getting the EDID data, so ideas welcome > there too. Feedback very welcome, thanks. > > Richard. > > _______________________________________________ > wayland-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
