From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [Intel-gfx] [PATCH 0/6] Intel Color Manager Framework Date: Tue, 25 Feb 2014 12:41:59 +0100 Message-ID: <20140225114158.GB723@ulmo.nvidia.com> References: <1392899847-2641-1-git-send-email-shashank.sharma@intel.com> <20140220131129.GG3852@intel.com> <20140221091706.GJ3852@intel.com> <20140221144614.GK3852@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0207275443==" Return-path: In-Reply-To: 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: Alex Deucher Cc: "intel-gfx@lists.freedesktop.org" , "Shankar, Uma" , "dri-devel@lists.freedesktop.org" , "Sharma, Shashank" List-Id: dri-devel@lists.freedesktop.org --===============0207275443== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v9Ux+11Zm5mwPlX6" Content-Disposition: inline --v9Ux+11Zm5mwPlX6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 21, 2014 at 10:41:14AM -0500, Alex Deucher wrote: > On Fri, Feb 21, 2014 at 9:46 AM, Ville Syrj=C3=A4l=C3=A4 > wrote: > > On Fri, Feb 21, 2014 at 02:20:24PM +0000, Sharma, Shashank wrote: > >> Hi Ville, > >> > >> Thanks for your time and comments. > >> I can understand two basic problems what you see in this implementatio= n: > >> > >> 1. The most important issue from my POV is that it can't be part of t= he 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 th= is, 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. > >> > >> 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 pr= operty in atomic modeset. > >> Or you can suggest us the expected interface, and we can work on modif= ying that as per expectation. > > > > The exptected interface will be range properties for stuff like > > brightness, contrast etc. controls. There are already such things as > > connector properties, but we're going to want something similar as > > plane or crtc properties. One thing that worries me about such > > properties though is whether we can make them hardware agnostic and > > yet allow userspace precise control over the final image. That is, if we > > map some fixed input range to a hardware specific output range, userspa= ce > > can't know how the actual output will change when the input changes. On > > the other hand if the input is hardware specific, userspace can't know > > what value to put in there to get the expected change on the output sid= e. > > > > For bigger stuff like CSC matrices and gamma ramps we will want to use > > some reasonably well defined blobs. Ie. the internal strucuture of the > > blob has to be documented and it shouldn't contain more than necessary. > > Ie. just the CSC matrix coefficients for one matrix, or just the entries > > for a single gamma ramp. Again ideally we should make the blobs hardware > > agnostic, but still allow precise control over the output data. > > > > I think this is going to involve first going over our hardware features, > > trying to find the common patterns between different generations. If > > there's a way to make something that works across the board for us, or > > at least across a wide range, then we should also ask for some input on > > dri-devel whether the proposed property would work for other people. We > > may need to define new property types to more precisely define what the > > value of the property actually means. > > >=20 > Our hardware has similar features, so I'm sure there will be quite a > bit of common ground. I also vote for properties. Thirded. Tegra should be able to use a hardware-agnostic description of these as well. I wonder if perhaps VESA or some other standard already defines such a format for some of these properties. Thierry --v9Ux+11Zm5mwPlX6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTDIGGAAoJEN0jrNd/PrOhFlAQAITSY0Z0HumxoAaiQBOldNIs WT0eEKVqgkQ868aoogiy3XFtRkyR3JIze4cj5fx82HNGBxJMTf5lkAqHrOJeZeq4 RcZqwO/BqXX5/lhGPPK9MMamAQ15x3UGBLi+jcAlAsOe5F7kIm3plIUjQYbnzDfU XGJXJhsId8GNraB9tfMk2RijcVuQXKcOEyIKS0tBR00wcg2Lo3ZgRMMQLC+g9Uf2 bp8fLly9YTEwFqmz/NImVdhb621oPyeeI18TnhIdOakGKkTTQZhpjNJje9quk8FJ b+BKYRq9ukLHSpIy6h19rTSf3Fo9ammVsWEtTXTJVMOxeWcFQvHIDTUF5YVbWPtl VCYOhe5V5BeokM0W4toR/lbjr2b6aW4zpOYBZoA2et8TV8jEgVBDzh9BbFaQPKG/ l3OH9ack35RumHOF9RqwnwY0J1MI0wYsYvSkex7f/TOVrz34j4VgjzG8Cv+uoEDI DWJpu79B9q9kKXO1Lti5L6Q3a8D8oG1/XwSZbsFulCKHIETkPEBDoErgoIFs3guO /JcXmeDe4A6XoXtMBFeuHZDSPWHTcY31Ls9aY4026a/Hfg+hRTF15IGyIT0XFZBv TuijkbLQNBWqBh1yWJeX/VTjfo3U3quYFDCgsVSo9NfE9TjMpwSl2KhyFPuUZwVq eqX3Vj8VQjrKEdLqVm7L =D5CY -----END PGP SIGNATURE----- --v9Ux+11Zm5mwPlX6-- --===============0207275443== 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 --===============0207275443==--