[Intel-gfx] [PATCH 0/6] Intel Color Manager Framework

[Sean Paul]

On Fri, Feb 21, 2014 at 9:49 AM, Rob Clark <robdclark at gmail.com> wrote:
> On Fri, Feb 21, 2014 at 9:20 AM, Sharma, Shashank
> <shashank.sharma at intel.com> wrote:
>> Hi Ville,
>>
>> Thanks for your time and comments.
>> I can understand two basic problems what you see in this implementation:
>>
>> 1.  The most important issue from my POV is that it can't be part of the atomic modeset.
>> 2.  it make the whole API inconsistent.
>>
>> I am not sure if its good to block all current implementation because we have thought something for this in atomic modeset.
>> I think even in atomic modeset we need the core implementation like this, but the interface would be different, which might come in from of a DRM property.
>> So at that time we can use this core implementation as it is, only the interfaces/framework needs to be changed.
>
> What I would suggest is re-form the userspace facing API to be
> properties.. if needed we can add a setblobprop ioctl (Sean Paul was,
> I think, adding that already).

This is news to me ;-)

I'm pulling the atomic stuff into the CrOS tree, but I think Rahul
Sharma is the guy you're looking for wrt setblobprop
(http://www.spinics.net/lists/dri-devel/msg54010.html).

Sean


> Then userspace and use setprop ioctls
> for now, and optionally atomic ioctl later when it is in place.  No
> reason for it to be blocked waiting for atomic.
>
> btw, I didn't look into the patches yet, but full-nak on idea of
> exposing via sysfs.  This should be the sort of thing that is set by
> the process that has mastership on the drm device, which we can't
> enforce via sysfs.  Using properties seems like the way to go.
>
> BR,
> -R
>
>> In this way we can always go ahead with a current implementation, and can just change the interfaces to fit in to the final interface like DRM property in atomic modeset.
>> Or you can suggest us the expected interface, and we can work on modifying that as per expectation.