From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: DRM Atomic property for color-space conversion Date: Thu, 16 Mar 2017 16:30:59 +0200 Message-ID: <20170316143059.GG31595@intel.com> References: <20170127172324.GB12018@e106950-lin.cambridge.arm.com> <20170130133513.GO31595@intel.com> <20170131123329.GB24500@e106950-lin.cambridge.arm.com> <20170131151546.GT31595@intel.com> <20170131155541.GF11506@e106950-lin.cambridge.arm.com> <20170316140725.GF31595@intel.com> <0cff6bab-7593-d3d2-f3b5-71dc21669dab@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id 243E16E159 for ; Thu, 16 Mar 2017 14:31:04 +0000 (UTC) Content-Disposition: inline In-Reply-To: <0cff6bab-7593-d3d2-f3b5-71dc21669dab@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: "Sharma, Shashank" Cc: liviu.dudau@arm.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, mihail.atanassov@arm.com, linux-media@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org T24gVGh1LCBNYXIgMTYsIDIwMTcgYXQgMDQ6MjA6MjlQTSArMDIwMCwgU2hhcm1hLCBTaGFzaGFu ayB3cm90ZToKPiBSZWdhcmRzCj4gCj4gU2hhc2hhbmsKPiAKPiAKPiBPbiAzLzE2LzIwMTcgNDow NyBQTSwgVmlsbGUgU3lyasOkbMOkIHdyb3RlOgo+ID4gT24gVHVlLCBKYW4gMzEsIDIwMTcgYXQg MDM6NTU6NDFQTSArMDAwMCwgQnJpYW4gU3RhcmtleSB3cm90ZToKPiA+PiBPbiBUdWUsIEphbiAz MSwgMjAxNyBhdCAwNToxNTo0NlBNICswMjAwLCBWaWxsZSBTeXJqw6Rsw6Qgd3JvdGU6Cj4gPj4+ IE9uIFR1ZSwgSmFuIDMxLCAyMDE3IGF0IDEyOjMzOjI5UE0gKzAwMDAsIEJyaWFuIFN0YXJrZXkg d3JvdGU6Cj4gPj4+PiBIaSwKPiA+Pj4+Cj4gPj4+PiBPbiBNb24sIEphbiAzMCwgMjAxNyBhdCAw MzozNToxM1BNICswMjAwLCBWaWxsZSBTeXJqw6Rsw6Qgd3JvdGU6Cj4gPj4+Pj4gT24gRnJpLCBK YW4gMjcsIDIwMTcgYXQgMDU6MjM6MjRQTSArMDAwMCwgQnJpYW4gU3RhcmtleSB3cm90ZToKPiA+ Pj4+Pj4gSGksCj4gPj4+Pj4+Cj4gPj4+Pj4+IFdlJ3JlIGxvb2tpbmcgdG8gZW5hYmxlIHRoZSBw ZXItcGxhbmUgY29sb3IgbWFuYWdlbWVudCBoYXJkd2FyZSBpbgo+ID4+Pj4+PiBNYWxpLURQIHdp dGggYXRvbWljIHByb3BlcnRpZXMsIHdoaWNoIGhhcyBzcGFya2VkIHNvbWUgY29udmVyc2F0aW9u Cj4gPj4+Pj4+IGFyb3VuZCBob3cgdG8gaGFuZGxlIFlDYkNyIGZvcm1hdHMuCj4gPj4+Pj4+Cj4g Pj4+Pj4+IEFzIGl0IHN0YW5kcyB0b2RheSwgaXQncyBhc3N1bWVkIHRoYXQgYSBkcml2ZXIgd2ls bCBpbXBsaWNpdGx5ICJkbyB0aGUKPiA+Pj4+Pj4gcmlnaHQgdGhpbmciIHRvIGRpc3BsYXkgYSBZ Q2JDciBidWZmZXIuCj4gPj4+Pj4+Cj4gPj4+Pj4+IFlDYkNyIGRhdGEgb2Z0ZW4gdXNlcyBkaWZm ZXJlbnQgZ2FtbWEgY3VydmVzIGFuZCBzaWduYWwgcmFuZ2VzIChlLmcuCj4gPj4+Pj4+IEJULjYw OSwgQlQuNzAxLCBCVC4yMDIwLCBzdHVkaW8gcmFuZ2UsIGZ1bGwtcmFuZ2UpLCBzbyBpdHMgZGVz aXJhYmxlCj4gPj4+Pj4+IHRvIGJlIGFibGUgdG8gZXhwbGljaXRseSBjb250cm9sIHRoZSBZQ2JD ciB0byBSR0IgY29udmVyc2lvbiBwcm9jZXNzCj4gPj4+Pj4+IGZyb20gdXNlcnNwYWNlLgo+ID4+ Pj4+Pgo+ID4+Pj4+PiBXZSdyZSBwcm9wb3NpbmcgYWRkaW5nIGEgIkNTQyIgKGNvbG9yLXNwYWNl IGNvbnZlcnNpb24pIHByb3BlcnR5IHRvCj4gPj4+Pj4+IGNvbnRyb2wgdGhpcyAtIHByaW1hcmls eSBwZXItcGxhbmUgZm9yIGZyYW1lYnVmZmVyLT5waXBlbGluZSBDU0MsIGJ1dAo+ID4+Pj4+PiBw ZXJoYXBzIG9uZSBwZXIgQ1JUQyB0b28gZm9yIGRldmljZXMgd2hpY2ggaGF2ZSBhbiBSR0IgcGlw ZWxpbmUgYW5kCj4gPj4+Pj4+IHdhbnQgdG8gb3V0cHV0IGluIFlVViB0byB0aGUgZGlzcGxheToK PiA+Pj4+Pj4KPiA+Pj4+Pj4gTmFtZTogIkNTQyIKPiA+Pj4+Pj4gVHlwZTogRU5VTSB8IEFUT01J QzsKPiA+Pj4+Pj4gRW51bSB2YWx1ZXMgKHJlcHJlc2VudGF0aXZlKToKPiA+Pj4+Pj4gImRlZmF1 bHQiOgo+ID4+Pj4+PiAJU2FtZSBiZWhhdmlvdXIgYXMgbm93LiAiU29tZSBraW5kIiBvZiBZQ2JD ci0+UkdCIGNvbnZlcnNpb24KPiA+Pj4+Pj4gCWZvciBZQ2JDciBidWZmZXJzLCBieXBhc3MgZm9y IFJHQiBidWZmZXJzCj4gPj4+Pj4+ICJkaXNhYmxlIjoKPiA+Pj4+Pj4gCUV4cGxpY2l0bHkgZGlz YWJsZSBhbGwgY29sb3JzcGFjZSBjb252ZXJzaW9uIChpLmUuIHVzZSBhbgo+ID4+Pj4+PiAJaWRl bnRpdHkgbWF0cml4KS4KPiA+Pj4+Pj4gIllDYkNyIHRvIFJHQjogQlQuNzA5IjoKPiA+Pj4+Pj4g CU9ubHkgdmFsaWQgZm9yIFlDYkNyIGZvcm1hdHMuIENTQyBpbiBhY2NvcmRhbmNlIHdpdGggQlQu NzA5Cj4gPj4+Pj4+IAl1c2luZyBbMTYuLjIzNV0gZm9yICg4LWJpdCkgbHVtYSB2YWx1ZXMsIGFu ZCBbMTYuLjI0MF0gZm9yCj4gPj4+Pj4+IAk4LWJpdCBjaHJvbWEgdmFsdWVzLiBGb3IgMTAtYml0 IGZvcm1hdHMsIHRoZSByYW5nZSBsaW1pdHMgYXJlCj4gPj4+Pj4+IAltdWx0aXBsaWVkIGJ5IDQu Cj4gPj4+Pj4+ICJZQ2JDciB0byBSR0I6IEJULjcwOSBmdWxsLXN3aW5nIjoKPiA+Pj4+Pj4gCU9u bHkgdmFsaWQgZm9yIFlDYkNyIGZvcm1hdHMuIENTQyBpbiBhY2NvcmRhbmNlIHdpdGggQlQuNzA5 LAo+ID4+Pj4+PiAJYnV0IHVzaW5nIHRoZSBmdWxsIHJhbmdlIG9mIGVhY2ggY2hhbm5lbC4KPiA+ Pj4+Pj4gIllDYkNyIHRvIFJHQjogVXNlIENUTSI6Kgo+ID4+Pj4+PiAJT25seSB2YWxpZCBmb3Ig WUNiQ3IgZm9ybWF0cy4gVXNlIHRoZSBtYXRyaXggYXBwbGllZCB2aWEgdGhlCj4gPj4+Pj4+IAlw bGFuZSdzIENUTSBwcm9wZXJ0eQo+ID4+Pj4+PiAiUkdCIHRvIFJHQjogVXNlIENUTSI6Kgo+ID4+ Pj4+PiAJT25seSB2YWxpZCBmb3IgUkdCIGZvcm1hdHMuIFVzZSB0aGUgbWF0cml4IGFwcGxpZWQg dmlhIHRoZQo+ID4+Pj4+PiAJcGxhbmUncyBDVE0gcHJvcGVydHkKPiA+Pj4+Pj4gIlVzZSBDVE0i OioKPiA+Pj4+Pj4gCVZhbGlkIGZvciBhbnkgZm9ybWF0LiBVc2UgdGhlIG1hdHJpeCBhcHBsaWVk IHZpYSB0aGUgcGxhbmUncwo+ID4+Pj4+PiAJQ1RNIHByb3BlcnR5Cj4gPj4+Pj4+IC4uLiBhbnkg b3RoZXIgdmFsdWVzIGZvciBCVC42MDEsIEJULjIwMjAsIFJHQiB0byBZQ2JDciBldGMuIGV0Yy4g YXMKPiA+Pj4+Pj4gdGhleSBhcmUgcmVxdWlyZWQuCj4gPj4+Pj4gSGF2aW5nIHNvbWUgUkdCMlJH QiBhbmQgWUNCQ1IyUkdCIHRoaW5ncyBpbiB0aGUgc2FtZSBwcm9wZXJ0eSBzZWVtcwo+ID4+Pj4+ IHdlaXJkLiBJIHdvdWxkIGp1c3QgZ28gd2l0aCBzb21ldGhpbmcgdmVyeSBzaW1wbGUgbGlrZToK PiA+Pj4+Pgo+ID4+Pj4+IFlDQkNSX1RPX1JHQl9DU0M6Cj4gPj4+Pj4gKiBCVC42MDEKPiA+Pj4+ PiAqIEJULjcwOQo+ID4+Pj4+ICogY3VzdG9tIG1hdHJpeAo+ID4+Pj4+Cj4gPj4+PiBJIHRoaW5r IHdlJ3ZlIGFncmVlZCBpbiAjZHJpLWRldmVsIHRoYXQgdGhpcyBDU0MgcHJvcGVydHkKPiA+Pj4+ IGNhbid0L3Nob3VsZG4ndCBiZSBtYXBwZWQgb24tdG8gdGhlIGV4aXN0aW5nIChoYXJkd2FyZSBp bXBsZW1lbnRpbmcKPiA+Pj4+IHRoZSkgQ1RNIHByb3BlcnR5IC0gZXZlbiBpbiB0aGUgY2FzZSBv ZiBwZXItcGxhbmUgY29sb3IgbWFuYWdlbWVudCAtCj4gPj4+PiBiZWNhdXNlIENTQyBuZWVkcyB0 byBiZSBkb25lIGJlZm9yZSBERUdBTU1BLgo+ID4+Pj4KPiA+Pj4+IFNvLCBJJ20gaW4gZmF2b3Vy IG9mIGdvaW5nIHdpdGggd2hhdCB5b3Ugc3VnZ2VzdGVkIGluIHRoZSBmaXJzdCBwbGFjZToKPiA+ Pj4+Cj4gPj4+PiBBIG5ldyBZQ0JDUl9UT19SR0JfQ1NDIHByb3BlcnR5LCBlbnVtIHR5cGUsIHdp dGggYSBsaXN0IG9mIGZpeGVkCj4gPj4+PiBjb252ZXJzaW9ucy4gSSdkIGRyb3AgdGhlIGN1c3Rv bSBtYXRyaXggZm9yIG5vdywgYXMgd2UnZCBuZWVkIHRvIGFkZAo+ID4+Pj4gYW5vdGhlciBwcm9w ZXJ0eSB0byBhdHRhY2ggdGhlIGN1c3RvbSBtYXRyaXggYmxvYiB0b28uCj4gPj4+Pgo+ID4+Pj4g SSBzdGlsbCB0aGluayB3ZSBuZWVkIGEgd2F5IHRvIHNwZWNpZnkgd2hldGhlciB0aGUgc291cmNl IGRhdGEgcmFuZ2UKPiA+Pj4+IGlzIGJyb2FkY2FzdC9mdWxsLXJhbmdlLCBzbyBwZXJoYXBzIHRo ZSBlbnVtIGxpc3Qgc2hvdWxkIGJlIGV4cGFuZGVkCj4gPj4+PiB0byBhbGwgY29tYmluYXRpb25z IG9mIEJULjYwMS9CVC43MDkgKyBicm9hZGNhc3QvZnVsbC1yYW5nZS4KPiA+Pj4gU291bmRzIHJl YXNvbmFibGUuIE5vdCB0aGF0IG11Y2ggZnVsbCByYW5nZSBZQ2JDciBzdHVmZiBvdXQgdGhlcmUK PiA+Pj4gcGVyaGFwcy4gV2VsbCwgYXBhcnQgZnJvbSBqcGVncyBJIHN1cHBvc2UuIEJ1dCBubyBo YXJtIGluIGJlaW5nIGFibGUKPiA+Pj4gdG8gZGVhbCB3aXRoIGl0Lgo+ID4+Pgo+ID4+Pj4gKEkn bSBub3Qgc3VyZSB3aGF0IHRoZSBjYW5vbmljYWwgbmFtaW5nIGZvciBicm9hZGNhc3QvZnVsbC1y YW5nZSBpcywKPiA+Pj4+IHdlIGNhbGwgdGhlbSBuYXJyb3cgYW5kIHdpZGUpCj4gPj4+IFdlIHRl bmQgdG8gY2FsbCB0aGVtIGZ1bGwgdnMuIGxpbWl0ZWQgcmFuZ2UuIFRoYXQncyBob3cgb3VyCj4g Pj4+ICJCcm9hZGNhc3QgUkdCIiBwcm9wZXJ0eSBpcyBkZWZpbmVkIGFzIHdlbGwuCj4gPj4+Cj4g Pj4gT0ssIHVzaW5nIHRoZSBzYW1lIG9uZXMgc291bmRzIHNlbnNpYmxlLgo+ID4+Cj4gPj4+Pj4g QW5kIHRyeWluZyB0byB1c2UgdGhlIHNhbWUgdGhpbmcgZm9yIHRoZSBjcnRjIHN0dWZmIGlzIHBy b2JhYmx5IG5vdAo+ID4+Pj4+IGdvaW5nIHRvIGVuZCB3ZWxsLiBMaWtlIERhbmllbCBzYWlkIHdl IGFscmVhZHkgaGF2ZSB0aGUKPiA+Pj4+PiAnQnJvYWRjYXN0IFJHQicgcHJvcGVydHkgbXVkZHlp bmcgdGhlIHdhdGVycyB0aGVyZSwgYW5kIHRoYXQgc3R1ZmYKPiA+Pj4+PiBhbHNvIHRpZXMgaW4g d2l0aCB3aGF0IGNvbG9yc3BhY2Ugd2Ugc2lnbmFsIHRvIHRoZSBzaW5rIHZpYQo+ID4+Pj4+IGlu Zm9mcmFtZXMvd2hhdGV2ZXIgdGhlIERQIHRoaW5nIHdhcyBjYWxsZWQuIFNvIG15IGd1dCBmZWVs aW5nIGlzCj4gPj4+Pj4gdGhhdCB0cnlpbmcgdG8gdXNlIHRoZSBzYW1lIHByb3BlcnR5IGV2ZXJ5 d2hlcmUgd2lsbCBqdXN0IGVuZCB1cAo+ID4+Pj4+IG1lc3N5Lgo+ID4+Pj4gWWVhaCwgYWdyZWVk LiBJZi93aGVuIHNvbWVvbmUgd2FudHMgdG8gYWRkIENTQyBvbiB0aGUgb3V0cHV0IG9mIGEgQ1JU Qwo+ID4+Pj4gKGFmdGVyIEdBTU1BKSwgd2UgY2FuIGFkZCBhIG5ldyBwcm9wZXJ0eS4KPiA+Pj4+ Cj4gPj4+PiBUaGF0IG1ha2VzIG1lIHdvbmRlciBhYm91dCBjYWxsaW5nIHRoaXMgb25lIFNPVVJD RV9ZQ0JDUl9UT19SR0JfQ1NDIHRvCj4gPj4+PiBiZSBleHBsaWNpdCB0aGF0IGl0IGRlc2NyaWJl cyB0aGUgc291cmNlIGRhdGEuIFRoZW4gd2UgY2FuIGxhdGVyIGFkZAo+ID4+Pj4gU0lOS19SR0Jf VE9fWUNCQ1JfQ1NDLCBhbmQgaXQgd2lsbCBiZSByZWFzb25hYmx5IG9idmlvdXMgdGhhdCBpdHMK PiA+Pj4+IHZhbHVlIGRlc2NyaWJlcyB0aGUgb3V0cHV0IGRhdGEgcmF0aGVyIHRoYW4gdGhlIGlu cHV0IGRhdGEuCj4gPj4+IFNvdXJjZSBhbmQgc2luayBoYXZlIGEgc2xpZ2h0IGNvbm5vdGF0aW9u IGluIG15IG1pbmQgd3J0LiB0aGUgYm94IHRoYXQKPiA+Pj4gcHJvZHVjZXMgdGhlIGRpc3BsYXkg c2lnbmFsIGFuZCB0aGUgYm94IHRoYXQgZWF0cyB0aGUgc2lnbmFsLiBTbyB0cnlpbmcKPiA+Pj4g dG8gdXNlIHRoZSBzYW1lIHRlcm1zIHRvIGRlc2NyaWJlIHRoZSBpbnRlcm5hbHMgb2YgdGhlIHBp cGVsaW5lIGluc2lkZQo+ID4+PiB0aGUgInNvdXJjZSBib3giIG1pZ3RoIGxlYWQgdG8gc29tZSBj b25mdXNpb24uIEJ1dCB3ZSBkbyBwcm9iYWJseSBuZWVkCj4gPj4+IHNvbWUgZGVjZW50IG5hbWVz IGZvciB0aGVzZSB0byBtYWtlIHRoZSBsYXlvdXQgb2YgdGhlIHBpcGVsaW5lIGNsZWFyLgo+ID4+ PiBJbnB1dC9vdXRwdXQgYXJlIHRoZSBvdGhlciBuYW1lcyB0aGF0IHBvcHBlZCB0byBteSBtaW5k IGJ1dCB0aG9zZSBhcmVuJ3QKPiA+Pj4gbmVjZXNzYXJpbHkgYW55IGJldHRlci4gQnV0IGluIHRo ZSBlbmQgSSB0aGluayBJIGNvdWxkIGxpdmUgd2l0aCB3aGF0ZXZlcgo+ID4+PiBuYW1lcyB3ZSBo YXBwZW4gdG8gcGljaywgYXMgbG9uZyBhcyB3ZSBkb2N1bWVudCB0aGUgcGlwZWxpbmUgY2xlYXJs eS4KPiA+Pj4KPiA+Pj4gTG9uZyBhZ28gSSBkaWQgd29uZGVyIGlmIHdlIHNob3VsZCBqdXN0IHN0 YXJ0IGluZGV4aW5nIHRoZXNlIHRoaW5ncwo+ID4+PiBzb21laG93LCBhbmQgdGhlbiBqdXN0IGxv b2tpbmcgYXQgdGhlIGluZGV4IHNob3VsZCB0ZWxsIHlvdSB0aGUgb3JkZXIKPiA+Pj4gb2YgdGhl IG9wZXJhdGlvbnMuIEJ1dCB3ZSBhbHJlYWR5IGhhdmUgdGhlIGN0bS9nYW1tYSB3L28gYW55IGlu ZGV4ZXMgc28KPiA+Pj4gdGhhdCBpZGVhIHByb2JhYmx5IGlzbid0IHNvIGdyZWF0IGFueW1vcmUu Cj4gPj4+Cj4gPj4+PiBJIHdhbnQgdG8gYXZvaWQgY29uZnVzaW9uIGNhdXNlZCBieSBlbmRpbmcg dXAgd2l0aCB0d28KPiA+Pj4+IHtDU31fVE9fe0NTfV9DU0MgcHJvcGVydGllcywgd2hlcmUgb25l IGlzIGRlc2NyaWJpbmcgdGhlIGRhdGEgdG8gdGhlCj4gPj4+PiBsZWZ0IG9mIGl0LCBhbmQgdGhl IG90aGVyIGRlc2NyaWJpbmcgdGhlIGRhdGEgdG8gdGhlIHJpZ2h0IG9mIGl0LCB3aXRoCj4gPj4+ PiBubyByZWFsIHdheSBvZiB0ZWxsaW5nIHdoaWNoIHdheSBhcm91bmQgaXQgaXMuCj4gPj4+IE5v dCByZWFsbHkgc3VyZSB3aGF0IHlvdSBtZWFuLiBJdCBzaG91bGQgYWx3YXlzIGJlCj4gPj4+IDxs ZWZ0Pl90b188cmlnaHQ+X2NzYy4KPiA+PiBBZ3JlZWQsIGxlZnQtdG8tcmlnaHQuIEJ1dCBmb3Ig aW5zdGFuY2Ugb24gYSBDU0MgcHJvcGVydHkgcmVwcmVzZW50aW5nCj4gPj4gYSBDUlRDIG91dHB1 dCBDU0MgKGp1c3QgYmVmb3JlIGhpdHRpbmcgdGhlIGNvbm5lY3RvciksIHdoaWNoIGhhcHBlbnMK PiA+PiB0byBiZSBjb252ZXJ0aW5nIFJHQiB0byBZQ2JDcjoKPiA+Pgo+ID4+IENSVEMgLT4gR0FN TUEgLT4gUkdCX1RPX1lDQkNSX0NTQwo+ID4+Cj4gPj4gLi4udGhlIGVudW0gdmFsdWUgIkJULjYw MSBMaW1pdGVkIiBtZWFucyB0aGF0IHRoZSBkYXRhIG9uIHRoZSAqcmlnaHQqCj4gPj4gb2YgUkdC X1RPX1lDQkNSX0NTQyBpcyAiQlQuNjAxIExpbWl0ZWQiCj4gPj4KPiA+PiBPbiB0aGUgb3RoZXIg aGFuZCBmb3IgYSBDU0Mgb24gdGhlIGlucHV0IG9mIGEgcGxhbmUsIHdoaWNoIGhhcHBlbnMgdG8K PiA+PiBiZSBjb252ZXJ0aW5nIFlDYkNyIHRvIFJHQjoKPiA+Pgo+ID4+IFJBTSAtPiBZQ0JDUl9U T19SR0JfQ1NDIC0+IERFR0FNTUEKPiA+Pgo+ID4+IC4uLnRoZSBlbnVtIHZhbHVlICJCVC42MDEg TGltaXRlZCIgbWVhbnMgdGhhdCB0aGUgZGF0YSBvbiB0aGUgKmxlZnQqCj4gPj4gb2YgWUNCQ1Jf VE9fUkdCX0NTQyBpcyAiQlQuNjAxIExpbWl0ZWQiLgo+ID4+Cj4gPj4gSW5kaWNhdGluZyBpbiB0 aGUgcHJvcGVydHkgbmFtZSB3aGV0aGVyIGl0cyB2YWx1ZSBpcyBkZXNjcmliaW5nIHRoZQo+ID4+ IGRhdGEgb24gdGhlIGxlZnQgb3IgdGhlIHJpZ2h0IGlzIG5lZWRlZCAoYW5kIEkgZG9uJ3QgdGhp bmsgaW5mZXJyaW5nCj4gPj4gdGhhdCAiaXQncyBhbHdheXMgdGhlIFlDQkNSIG9uZSIgaXMgdGhl IGNvcnJlY3QgYXBwcm9hY2gpLgo+ID4+Cj4gPj4gSW4gbXkgZXhhbXBsZSBhYm92ZSwgIlNPVVJD RV94eHgiIHdvdWxkIG1lYW4gdGhlIGVudW0gdmFsdWUgaXMKPiA+PiBkZXNjcmliaW5nIHRoZSAi c291cmNlIiBkYXRhIChpLmUuIHRoZSBkYXRhIG9uIHRoZSBsZWZ0KSBhbmQKPiA+PiAiU0lOS194 eHgiIHdvdWxkIG1lYW4gdGhlIGVudW0gdmFsdWUgaXMgZGVzY3JpYmluZyB0aGUgInNpbmsiIGRh dGEKPiA+PiAoaS5lLiB0aGUgZGF0YSBvbiB0aGUgcmlnaHQpLiBUaGlzIGRvZXNuJ3QgbmVjZXNz YXJpbHkgbmVlZCB0byBpbmZlciBhCj4gPj4gcGFydGljdWxhciBwb2ludCBpbiB0aGUgcGlwZWxp bmUuCj4gPiBSaWdodCwgc28gSSBndWVzcyB5b3Ugd2FudCB0aGUgdmFsdWVzIHRvIGJlIG5hbWVk ICI8YT4gdG8gPGI+IiBhcyB3ZWxsPwo+ID4gWWVzLCBJIHRoaW5rIHdlJ2xsIGJlIHdhbnRpbmcg dGhhdCBhcyB3ZWxsLgo+ID4KPiA+IFNvIHdoYXQgd2UgbWlnaHQgbmVlZCBpcyBzb21ldGhpbmcg bGlrZToKPiA+IGVudW0gWUNCQ1JfVE9fUkdCX0NTQwo+ID4gICAqIFlDYkNyIEJULjYwMSBsaW1p dGVkIHRvIFJHQiBCVC43MDkgZnVsbAo+ID4gICAqIFlDYkNyIEJULjcwOSBsaW1pdGVkIHRvIFJH QiBCVC43MDkgZnVsbCA8dGhpcyB3b3VsZCBiZSB0aGUgbGlrZWx5IGRlZmF1bHQgdmFsdWUgSU1P Pgo+ID4gICAqIFlDYkNyIEJULjYwMSBsaW1pdGVkIHRvIFJHQiBCVC4yMDIwIGZ1bGwKPiA+ICAg KiBZQ2JDciBCVC43MDkgbGltaXRlZCB0byBSR0IgQlQuMjAyMCBmdWxsCj4gPiAgICogWUNiQ3Ig QlQuMjAyMCBsaW1pdGVkIHRvIFJHQiBCVC4yMDIwIGZ1bGwKPiA+Cj4gPiBBbmQgdGhhbmtzIHRv IEJULjIwMjAgd2UnbGwgbmVlZCBhIFJHQi0+UkdCIENTQyBwcm9wZXJ0eSBhcyB3ZWxsLiBFZzoK PiA+IGVudW0gUkdCX1RPX1JHQl9DU0MKPiA+ICAgKiBieXBhc3MgKG9yIHNlcGFyYXRlIDcwOS0+ NzA5LCAyMDIwLT4yMDIwPykgPHRoaXMgd291bGQgYmUgdGhlIGRlZmF1bHQ+Cj4gPiAgICogUkdC IEJULjcwOSBmdWxsIHRvIFJHQiBCVC4yMDIwIGZ1bGwKPiA+Cj4gPiBBbHRlcm5hdGl2ZXMgd291 bGQgaW52b2x2ZSB0d28gcHJvcGVydGllcyB0byBkZWZpbmUgdGhlIGlucHV0IGFuZCBvdXRwdXQK PiA+IGZyb20gdGhlIENTQyBzZXBhcmF0ZWx5LCBidXQgdGhlbiB5b3UgbG9zZSB0aGUgY2FwYWJp bGl0eSB0byBzZWUgd2hpY2gKPiA+IGNvbWJpbmF0aW9ucyBhcmUgYWN0dWFsbHkgc3Vwb29ydGVk Lgo+IEkgd2FzIHRoaW5raW5nIGFib3V0IHRoaXMgdG9vLCBvciB3b3VsZCBpdCBtYWtlIG1vcmUg c2Vuc2UgdG8gY3JlYXRlIHR3byAKPiBwcm9wZXJ0aWVzOgo+IC0gb25lIGZvciBnYW11dCBtYXBw aW5nIChjYXNlcyBsaWtlIFJHQjcwOS0+UkdCMjAyMCkKPiAtIG90aGVyIG9uZSBmb3IgQ29sb3Ig c3BhY2UgY29udmVyc2lvbiAoY2FzZXMgbGlsZSBZVVYgNzA5IC0+IFJHQiA3MDkpCj4gCj4gR2Ft dXQgbWFwcGluZyBjYW4gcmVwcmVzZW50IGFueSBvZiB0aGUgZml4IGZ1bmN0aW9uIG1hcHBpbmcs IHdlcmVhcyBDU0MgCj4gY2FuIGJyaW5nIHVwIGFueSBwcm9ncmFtbWFibGUgbWF0cml4Cj4gCj4g SW50ZXJuYWxseSB0aGVzZSBwcm9wZXJ0aWVzIGNhbiB1c2UgdGhlIHNhbWUgSFcgdW5pdCBvciBl dmVuIHNhbWUgZnVuY3Rpb24uCj4gRG9lcyBpdCBzb3VuZCBhbnkgZ29vZCA/CgpJdCdzIGNlcnRh aW5seSBwb3NzaWJsZS4gT25lIHByb2JsZW0gaXMgdGhhdCB3ZSBjYW4ndCBpbmZvcm0gdXNlcnNw YWNlCnVwZnJvbnQgd2hpY2ggY29tYmluYXRpb25zIGFyZSBzdXBwb3J0ZWQuIFdoZXRoZXIgdGhh dCdzIGEgcmVhbCBwcm9ibGVtCkknbSBub3Qgc3VyZS4gV2l0aCBhdG9taWMgdXNlcnNwYWNlIGNh biBvZiBjb3Vyc2UgY2hlY2sgdXBmcm9udCBpZgpzb21ldGhpbmcgY2FuIGJlIGRvbmUgb3Igbm90 LCBidXQgdGhlIG1haW4gcHJvYmxlbSBpcyB0aGVuIGNvbWluZyB1cAp3aXRoIGEgZmFsbGJhY2sg c3RyYXRlZ3kgdGhhdCBkb2Vzbid0IHN1Y2sgdG9vIGJhZGx5LgoKQW55d2F5cywgSSBkb24ndCB0 aGluayBJIGhhdmUgYW55IHN0cm9uZyBmYXZvcml0ZXMgaGVyZS4gV291bGQgYmUgbmljZQp0byBo ZWFyIHdoYXQgZXZlcnlvbmUgZWxzZSB0aGlua3MuCgotLSAKVmlsbGUgU3lyasOkbMOkCkludGVs IE9UQwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmkt ZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6 Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga05.intel.com ([192.55.52.43]:32851 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753056AbdCPOel (ORCPT ); Thu, 16 Mar 2017 10:34:41 -0400 Date: Thu, 16 Mar 2017 16:30:59 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: "Sharma, Shashank" Cc: Brian Starkey , dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, mihail.atanassov@arm.com, liviu.dudau@arm.com Subject: Re: DRM Atomic property for color-space conversion Message-ID: <20170316143059.GG31595@intel.com> References: <20170127172324.GB12018@e106950-lin.cambridge.arm.com> <20170130133513.GO31595@intel.com> <20170131123329.GB24500@e106950-lin.cambridge.arm.com> <20170131151546.GT31595@intel.com> <20170131155541.GF11506@e106950-lin.cambridge.arm.com> <20170316140725.GF31595@intel.com> <0cff6bab-7593-d3d2-f3b5-71dc21669dab@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0cff6bab-7593-d3d2-f3b5-71dc21669dab@intel.com> Sender: linux-media-owner@vger.kernel.org List-ID: On Thu, Mar 16, 2017 at 04:20:29PM +0200, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/16/2017 4:07 PM, Ville Syrjälä wrote: > > On Tue, Jan 31, 2017 at 03:55:41PM +0000, Brian Starkey wrote: > >> On Tue, Jan 31, 2017 at 05:15:46PM +0200, Ville Syrjälä wrote: > >>> On Tue, Jan 31, 2017 at 12:33:29PM +0000, Brian Starkey wrote: > >>>> Hi, > >>>> > >>>> On Mon, Jan 30, 2017 at 03:35:13PM +0200, Ville Syrjälä wrote: > >>>>> On Fri, Jan 27, 2017 at 05:23:24PM +0000, Brian Starkey wrote: > >>>>>> Hi, > >>>>>> > >>>>>> We're looking to enable the per-plane color management hardware in > >>>>>> Mali-DP with atomic properties, which has sparked some conversation > >>>>>> around how to handle YCbCr formats. > >>>>>> > >>>>>> As it stands today, it's assumed that a driver will implicitly "do the > >>>>>> right thing" to display a YCbCr buffer. > >>>>>> > >>>>>> YCbCr data often uses different gamma curves and signal ranges (e.g. > >>>>>> BT.609, BT.701, BT.2020, studio range, full-range), so its desirable > >>>>>> to be able to explicitly control the YCbCr to RGB conversion process > >>>>>> from userspace. > >>>>>> > >>>>>> We're proposing adding a "CSC" (color-space conversion) property to > >>>>>> control this - primarily per-plane for framebuffer->pipeline CSC, but > >>>>>> perhaps one per CRTC too for devices which have an RGB pipeline and > >>>>>> want to output in YUV to the display: > >>>>>> > >>>>>> Name: "CSC" > >>>>>> Type: ENUM | ATOMIC; > >>>>>> Enum values (representative): > >>>>>> "default": > >>>>>> Same behaviour as now. "Some kind" of YCbCr->RGB conversion > >>>>>> for YCbCr buffers, bypass for RGB buffers > >>>>>> "disable": > >>>>>> Explicitly disable all colorspace conversion (i.e. use an > >>>>>> identity matrix). > >>>>>> "YCbCr to RGB: BT.709": > >>>>>> Only valid for YCbCr formats. CSC in accordance with BT.709 > >>>>>> using [16..235] for (8-bit) luma values, and [16..240] for > >>>>>> 8-bit chroma values. For 10-bit formats, the range limits are > >>>>>> multiplied by 4. > >>>>>> "YCbCr to RGB: BT.709 full-swing": > >>>>>> Only valid for YCbCr formats. CSC in accordance with BT.709, > >>>>>> but using the full range of each channel. > >>>>>> "YCbCr to RGB: Use CTM":* > >>>>>> Only valid for YCbCr formats. Use the matrix applied via the > >>>>>> plane's CTM property > >>>>>> "RGB to RGB: Use CTM":* > >>>>>> Only valid for RGB formats. Use the matrix applied via the > >>>>>> plane's CTM property > >>>>>> "Use CTM":* > >>>>>> Valid for any format. Use the matrix applied via the plane's > >>>>>> CTM property > >>>>>> ... any other values for BT.601, BT.2020, RGB to YCbCr etc. etc. as > >>>>>> they are required. > >>>>> Having some RGB2RGB and YCBCR2RGB things in the same property seems > >>>>> weird. I would just go with something very simple like: > >>>>> > >>>>> YCBCR_TO_RGB_CSC: > >>>>> * BT.601 > >>>>> * BT.709 > >>>>> * custom matrix > >>>>> > >>>> I think we've agreed in #dri-devel that this CSC property > >>>> can't/shouldn't be mapped on-to the existing (hardware implementing > >>>> the) CTM property - even in the case of per-plane color management - > >>>> because CSC needs to be done before DEGAMMA. > >>>> > >>>> So, I'm in favour of going with what you suggested in the first place: > >>>> > >>>> A new YCBCR_TO_RGB_CSC property, enum type, with a list of fixed > >>>> conversions. I'd drop the custom matrix for now, as we'd need to add > >>>> another property to attach the custom matrix blob too. > >>>> > >>>> I still think we need a way to specify whether the source data range > >>>> is broadcast/full-range, so perhaps the enum list should be expanded > >>>> to all combinations of BT.601/BT.709 + broadcast/full-range. > >>> Sounds reasonable. Not that much full range YCbCr stuff out there > >>> perhaps. Well, apart from jpegs I suppose. But no harm in being able > >>> to deal with it. > >>> > >>>> (I'm not sure what the canonical naming for broadcast/full-range is, > >>>> we call them narrow and wide) > >>> We tend to call them full vs. limited range. That's how our > >>> "Broadcast RGB" property is defined as well. > >>> > >> OK, using the same ones sounds sensible. > >> > >>>>> And trying to use the same thing for the crtc stuff is probably not > >>>>> going to end well. Like Daniel said we already have the > >>>>> 'Broadcast RGB' property muddying the waters there, and that stuff > >>>>> also ties in with what colorspace we signal to the sink via > >>>>> infoframes/whatever the DP thing was called. So my gut feeling is > >>>>> that trying to use the same property everywhere will just end up > >>>>> messy. > >>>> Yeah, agreed. If/when someone wants to add CSC on the output of a CRTC > >>>> (after GAMMA), we can add a new property. > >>>> > >>>> That makes me wonder about calling this one SOURCE_YCBCR_TO_RGB_CSC to > >>>> be explicit that it describes the source data. Then we can later add > >>>> SINK_RGB_TO_YCBCR_CSC, and it will be reasonably obvious that its > >>>> value describes the output data rather than the input data. > >>> Source and sink have a slight connotation in my mind wrt. the box that > >>> produces the display signal and the box that eats the signal. So trying > >>> to use the same terms to describe the internals of the pipeline inside > >>> the "source box" migth lead to some confusion. But we do probably need > >>> some decent names for these to make the layout of the pipeline clear. > >>> Input/output are the other names that popped to my mind but those aren't > >>> necessarily any better. But in the end I think I could live with whatever > >>> names we happen to pick, as long as we document the pipeline clearly. > >>> > >>> Long ago I did wonder if we should just start indexing these things > >>> somehow, and then just looking at the index should tell you the order > >>> of the operations. But we already have the ctm/gamma w/o any indexes so > >>> that idea probably isn't so great anymore. > >>> > >>>> I want to avoid confusion caused by ending up with two > >>>> {CS}_TO_{CS}_CSC properties, where one is describing the data to the > >>>> left of it, and the other describing the data to the right of it, with > >>>> no real way of telling which way around it is. > >>> Not really sure what you mean. It should always be > >>> _to__csc. > >> Agreed, left-to-right. But for instance on a CSC property representing > >> a CRTC output CSC (just before hitting the connector), which happens > >> to be converting RGB to YCbCr: > >> > >> CRTC -> GAMMA -> RGB_TO_YCBCR_CSC > >> > >> ...the enum value "BT.601 Limited" means that the data on the *right* > >> of RGB_TO_YCBCR_CSC is "BT.601 Limited" > >> > >> On the other hand for a CSC on the input of a plane, which happens to > >> be converting YCbCr to RGB: > >> > >> RAM -> YCBCR_TO_RGB_CSC -> DEGAMMA > >> > >> ...the enum value "BT.601 Limited" means that the data on the *left* > >> of YCBCR_TO_RGB_CSC is "BT.601 Limited". > >> > >> Indicating in the property name whether its value is describing the > >> data on the left or the right is needed (and I don't think inferring > >> that "it's always the YCBCR one" is the correct approach). > >> > >> In my example above, "SOURCE_xxx" would mean the enum value is > >> describing the "source" data (i.e. the data on the left) and > >> "SINK_xxx" would mean the enum value is describing the "sink" data > >> (i.e. the data on the right). This doesn't necessarily need to infer a > >> particular point in the pipeline. > > Right, so I guess you want the values to be named " to " as well? > > Yes, I think we'll be wanting that as well. > > > > So what we might need is something like: > > enum YCBCR_TO_RGB_CSC > > * YCbCr BT.601 limited to RGB BT.709 full > > * YCbCr BT.709 limited to RGB BT.709 full > > * YCbCr BT.601 limited to RGB BT.2020 full > > * YCbCr BT.709 limited to RGB BT.2020 full > > * YCbCr BT.2020 limited to RGB BT.2020 full > > > > And thanks to BT.2020 we'll need a RGB->RGB CSC property as well. Eg: > > enum RGB_TO_RGB_CSC > > * bypass (or separate 709->709, 2020->2020?) > > * RGB BT.709 full to RGB BT.2020 full > > > > Alternatives would involve two properties to define the input and output > > from the CSC separately, but then you lose the capability to see which > > combinations are actually supoorted. > I was thinking about this too, or would it make more sense to create two > properties: > - one for gamut mapping (cases like RGB709->RGB2020) > - other one for Color space conversion (cases lile YUV 709 -> RGB 709) > > Gamut mapping can represent any of the fix function mapping, wereas CSC > can bring up any programmable matrix > > Internally these properties can use the same HW unit or even same function. > Does it sound any good ? It's certainly possible. One problem is that we can't inform userspace upfront which combinations are supported. Whether that's a real problem I'm not sure. With atomic userspace can of course check upfront if something can be done or not, but the main problem is then coming up with a fallback strategy that doesn't suck too badly. Anyways, I don't think I have any strong favorites here. Would be nice to hear what everyone else thinks. -- Ville Syrjälä Intel OTC