You can move the output->base.updated_color_profile assignment down to the other of the vfunc initializations.
You should remove the destroy and user_data fields from weston_color_profile. weston_cms_create_profile and weston_cms_load_profile should just return a pointer to weston_color_profile. Plugins should just exit if compositor->cms is already set in module_init. The call to colord_update_output_from_device in colord_output_added should probably be done in the GLib thread so it won't block the compositor. colord_update_output_from_device has to execute in the weston thread. I suggest you create a wayland event source and plug that in to the weston event loop. Make a thread safe list of pending output profile updates. When a new update is added trigger the event source. The event source handler should apply all the updates in the list. You should also remove any pending updates for outputs in colord_output_removed. On Thu, Apr 4, 2013 at 5:33 PM, Richard Hughes <hughsi...@gmail.com> wrote: > On 4 April 2013 07:58, John Kåre Alsaker <john.kare.alsa...@gmail.com> wrote: >> The weston_color_manager struct could lose the state field.... > > All fixed in the newest patchset, thanks for your detailed review. > >> I don't see a GLib event loop, so I'm curious to how the signals work. > > As discussed on IRC, I've used a thread for this. If wayland-glib can > do what we need in the future, I'll switch to using that if the dep is > okay. > > New patches attached. Comments and further review welcomed as usual. Thanks. > > Richard _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
