From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?St=E9phane_Marchesin?= Subject: Re: [Intel-gfx] [PATCH 0/6] Intel Color Manager Framework Date: Fri, 21 Feb 2014 10:57:49 -0800 Message-ID: References: <1392899847-2641-1-git-send-email-shashank.sharma@intel.com> <20140220131129.GG3852@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0298023587==" Return-path: In-Reply-To: <20140220131129.GG3852@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: =?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= Cc: Intel Graphics Development , uma.shankar@intel.com, "dri-devel@lists.freedesktop.org" , Shashank Sharma List-Id: dri-devel@lists.freedesktop.org --===============0298023587== Content-Type: multipart/alternative; boundary=001a1135185e24302604f2ef35f3 --001a1135185e24302604f2ef35f3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Feb 20, 2014 at 5:11 AM, Ville Syrj=E4l=E4 < 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 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). - 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. St=E9phane --001a1135185e24302604f2ef35f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Feb 20, 2014 at 5:11 AM, Ville Syrj=E4l=E4 <vi= lle.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 contr= ols, and if the interface isn't standard our user space won't be po= rtable across drivers. There are multiple reasons for using drm properties:=
- the KMS interface already provides a way to set the gamma ramp, whic= h this code seems to replicate.
- the KMS interface allows us to = name properties independently and enumerate them. It seems like right now y= ou 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 exis= ts).
- you can reuse the get/set infrastructure which is already in p= lace

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 d= ata (something similar to the device tree bindings). That way user space ca= n expect "color conversion matrix" to mean the same thing everywh= ere, to get the same data as input, and to work the same way on all platfor= ms.

St=E9phane

--001a1135185e24302604f2ef35f3-- --===============0298023587== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0298023587==--