[patches] Add a color management framework to weston

John Kåre Alsaker john.kare.alsaker at gmail.com
Thu Apr 4 09:11:32 PDT 2013


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 <hughsient at gmail.com> wrote:
> On 4 April 2013 07:58, John Kåre Alsaker <john.kare.alsaker at 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


More information about the wayland-devel mailing list