Re: [PATCH 0/6] Intel Color Manager Framework

["Stéphane Marchesin" <stephane.marchesin@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3422 bytes --]

On Fri, Feb 21, 2014 at 7:49 PM, Sharma, Shashank <shashank.sharma@intel.com
> wrote:

>    On Thu, Feb 20, 2014 at 5:11 AM, Ville Syrjälä <
> ville.syrjala@linux.intel.com> wrote:
>
> On Thu, Feb 20, 2014 at 06:07:21PM +0530, Shashank Sharma wrote:
> >> Color manager is a new framework in i915 driver, which provides
> >> a unified interface for various color correction methods supported
> >> by intel hardwares. The high level overview of this change is:
>
> >Would have been good to discuss this idea before implementing it. The
> >plan is to use kms properties for this kind of stuff which allows us
> >to hook it up with the upcoming atomic modeset API. Just yesterday there
> >was some discussion on #dri-devel about exposing user settable blob
> >properties even before the atomic modeset API lands (it was always the
> >plan for the atomic modeset API anyway). So based on a cursory glance,
> >this looks like it's going in the wrong direction.
>
>
>
> +1. We'e looking into hooking up color correction controls, and if the
> interface isn't standard our user space won't be portable across drivers.
> There are multiple reasons for using drm properties:
>
> - the KMS interface already provides a way to set the gamma ramp, which
> this code seems to replicate.
>
>
>
> The current KMS interface just initializes the gamma soft LUT palette
> registers, in 8 bit mode corresponding to unit gamma. It's impossible to
> apply accurate values corresponding to gamma=2.2 or 1.5 from KMS
>
> Because for that we need to program palette registers in 10.6 bit mode of
> hardware.
>

Then the existing interface should be extended. Otherwise you have two ways
to do the same thing...



>   >- the KMS interface allows us to name properties independently and
> enumerate them. It seems like right now you can't enumerate properties or
> guess what "property 0" is. I'd rather set the "Color conversion matrix"
> than remember to set >"property 0" (and even then, I'm not really sure it
> exists).
>
>
>
> All the properties are getting enumerated in color manager register
> function. The framework defines proper identifiers and mapping for each
> property, and every property is having a corresponding soft-lut to be
> loaded with correction values.
>

Correct me if I'm wrong, but I don't see a way for user space to query the
presence/absence of a given property. KMS allows that.



>
>
> - you can reuse the get/set infrastructure which is already in place
>
>
>
>
>
> >Another thing that came out of the discussion on irc is that we should
> standardize the properties. For example we could use a text file describing
> the name of the controls and the format of the data (something similar to
> the device tree >bindings). That way user space can expect "color
> conversion matrix" to mean the same thing everywhere, to get the same data
> as input, and to work the same way on all platforms.
>
> If you can please have a look on the header file, we are almost doing the
> same thing, in form of a protocol.
>

This protocol however is not extensible. With the KMS interface I can
already do the following from user space:
- query the existence of a given property
- set each property in a portable fashion (for example the same gamma ramp
code works on all DRM drivers)
- easily match properties to a given crtc

Stéphane

[-- Attachment #1.2: Type: text/html, Size: 7067 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx