[Intel-gfx] [PATCH 0/4] Color manager framework

[Ville Syrjälä]

On Thu, Sep 11, 2014 at 10:49:01AM +0200, Daniel Vetter wrote:
> On Thu, Sep 11, 2014 at 10:18 AM, Sharma, Shashank
> <shashank.sharma at intel.com> wrote:
> > Thanks Bob, Matt, Daniel for the review.
> > I will create a new patch set, complying all (almost :)) review comments from you all, and will float for review.
> >
> > Points I noted down overall:
> > 1.  No need for separate arrays for names, sizes etc (:( )
> > 2.  Create a _set_blob for blob_properties, and take that route for setting values of blob property in blob.
> 
> Please coordinate with Rob Clark/Ville on this, since the atomic ioctl
> also needs a set_blob. I'm not sure whether they have this already
> even. Adding them.

I'm pretty sure I had the blob thing in my atomic code. Hmm, yeah I used
it to shovel the mode into the kernel.

> 
> Also there's no need to block brightness/hue/... and such simpler
> properties on this, so best to submit patches in parallel and
> prioritize some of the simpler ones to get those in first.

Yes, please pick one hardware knob at a time and come up with a sane way
to represent that as a property. Let's not make things more complicated
by trying to refactor the code too much or come up with fancy new
frameworks. Just one property at a time please.

As for designing the properties I'd like them to have these properties:
- hardware agnostic if possible, ie. multiple drivers should be able to
  expose the same property and the compositor should not have to know
  which driver it's talking to.
- precisely describe what transformation is done to the data so that
  the compositor could have a fair chance of doing the same
  transformation via GL when not using hardware planes

Obviously those may not always be possible, but we should at least try
to come up with something like that before giving up and just shoveling
some hardware specific magic number across.

-- 
Ville Syrjälä
Intel OTC