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: Mon, 30 Jan 2017 15:35:13 +0200 Message-ID: <20170130133513.GO31595@intel.com> References: <20170127172324.GB12018@e106950-lin.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTPS id E867D6E444 for ; Mon, 30 Jan 2017 13:35:18 +0000 (UTC) Content-Disposition: inline In-Reply-To: <20170127172324.GB12018@e106950-lin.cambridge.arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Brian Starkey Cc: mihail.atanassov@arm.com, liviu.dudau@arm.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org T24gRnJpLCBKYW4gMjcsIDIwMTcgYXQgMDU6MjM6MjRQTSArMDAwMCwgQnJpYW4gU3RhcmtleSB3 cm90ZToKPiBIaSwKPiAKPiBXZSdyZSBsb29raW5nIHRvIGVuYWJsZSB0aGUgcGVyLXBsYW5lIGNv bG9yIG1hbmFnZW1lbnQgaGFyZHdhcmUgaW4KPiBNYWxpLURQIHdpdGggYXRvbWljIHByb3BlcnRp ZXMsIHdoaWNoIGhhcyBzcGFya2VkIHNvbWUgY29udmVyc2F0aW9uCj4gYXJvdW5kIGhvdyB0byBo YW5kbGUgWUNiQ3IgZm9ybWF0cy4KPiAKPiBBcyBpdCBzdGFuZHMgdG9kYXksIGl0J3MgYXNzdW1l ZCB0aGF0IGEgZHJpdmVyIHdpbGwgaW1wbGljaXRseSAiZG8gdGhlCj4gcmlnaHQgdGhpbmciIHRv IGRpc3BsYXkgYSBZQ2JDciBidWZmZXIuCj4gCj4gWUNiQ3IgZGF0YSBvZnRlbiB1c2VzIGRpZmZl cmVudCBnYW1tYSBjdXJ2ZXMgYW5kIHNpZ25hbCByYW5nZXMgKGUuZy4KPiBCVC42MDksIEJULjcw MSwgQlQuMjAyMCwgc3R1ZGlvIHJhbmdlLCBmdWxsLXJhbmdlKSwgc28gaXRzIGRlc2lyYWJsZQo+ IHRvIGJlIGFibGUgdG8gZXhwbGljaXRseSBjb250cm9sIHRoZSBZQ2JDciB0byBSR0IgY29udmVy c2lvbiBwcm9jZXNzCj4gZnJvbSB1c2Vyc3BhY2UuCj4gCj4gV2UncmUgcHJvcG9zaW5nIGFkZGlu ZyBhICJDU0MiIChjb2xvci1zcGFjZSBjb252ZXJzaW9uKSBwcm9wZXJ0eSB0bwo+IGNvbnRyb2wg dGhpcyAtIHByaW1hcmlseSBwZXItcGxhbmUgZm9yIGZyYW1lYnVmZmVyLT5waXBlbGluZSBDU0Ms IGJ1dAo+IHBlcmhhcHMgb25lIHBlciBDUlRDIHRvbyBmb3IgZGV2aWNlcyB3aGljaCBoYXZlIGFu IFJHQiBwaXBlbGluZSBhbmQKPiB3YW50IHRvIG91dHB1dCBpbiBZVVYgdG8gdGhlIGRpc3BsYXk6 Cj4gCj4gTmFtZTogIkNTQyIKPiBUeXBlOiBFTlVNIHwgQVRPTUlDOwo+IEVudW0gdmFsdWVzIChy ZXByZXNlbnRhdGl2ZSk6Cj4gImRlZmF1bHQiOgo+IAlTYW1lIGJlaGF2aW91ciBhcyBub3cuICJT b21lIGtpbmQiIG9mIFlDYkNyLT5SR0IgY29udmVyc2lvbgo+IAlmb3IgWUNiQ3IgYnVmZmVycywg YnlwYXNzIGZvciBSR0IgYnVmZmVycwo+ICJkaXNhYmxlIjoKPiAJRXhwbGljaXRseSBkaXNhYmxl IGFsbCBjb2xvcnNwYWNlIGNvbnZlcnNpb24gKGkuZS4gdXNlIGFuCj4gCWlkZW50aXR5IG1hdHJp eCkuCj4gIllDYkNyIHRvIFJHQjogQlQuNzA5IjoKPiAJT25seSB2YWxpZCBmb3IgWUNiQ3IgZm9y bWF0cy4gQ1NDIGluIGFjY29yZGFuY2Ugd2l0aCBCVC43MDkKPiAJdXNpbmcgWzE2Li4yMzVdIGZv ciAoOC1iaXQpIGx1bWEgdmFsdWVzLCBhbmQgWzE2Li4yNDBdIGZvcgo+IAk4LWJpdCBjaHJvbWEg dmFsdWVzLiBGb3IgMTAtYml0IGZvcm1hdHMsIHRoZSByYW5nZSBsaW1pdHMgYXJlCj4gCW11bHRp cGxpZWQgYnkgNC4KPiAiWUNiQ3IgdG8gUkdCOiBCVC43MDkgZnVsbC1zd2luZyI6Cj4gCU9ubHkg dmFsaWQgZm9yIFlDYkNyIGZvcm1hdHMuIENTQyBpbiBhY2NvcmRhbmNlIHdpdGggQlQuNzA5LAo+ IAlidXQgdXNpbmcgdGhlIGZ1bGwgcmFuZ2Ugb2YgZWFjaCBjaGFubmVsLgo+ICJZQ2JDciB0byBS R0I6IFVzZSBDVE0iOioKPiAJT25seSB2YWxpZCBmb3IgWUNiQ3IgZm9ybWF0cy4gVXNlIHRoZSBt YXRyaXggYXBwbGllZCB2aWEgdGhlCj4gCXBsYW5lJ3MgQ1RNIHByb3BlcnR5Cj4gIlJHQiB0byBS R0I6IFVzZSBDVE0iOioKPiAJT25seSB2YWxpZCBmb3IgUkdCIGZvcm1hdHMuIFVzZSB0aGUgbWF0 cml4IGFwcGxpZWQgdmlhIHRoZQo+IAlwbGFuZSdzIENUTSBwcm9wZXJ0eQo+ICJVc2UgQ1RNIjoq Cj4gCVZhbGlkIGZvciBhbnkgZm9ybWF0LiBVc2UgdGhlIG1hdHJpeCBhcHBsaWVkIHZpYSB0aGUg cGxhbmUncwo+IAlDVE0gcHJvcGVydHkKPiAuLi4gYW55IG90aGVyIHZhbHVlcyBmb3IgQlQuNjAx LCBCVC4yMDIwLCBSR0IgdG8gWUNiQ3IgZXRjLiBldGMuIGFzCj4gdGhleSBhcmUgcmVxdWlyZWQu CgpIYXZpbmcgc29tZSBSR0IyUkdCIGFuZCBZQ0JDUjJSR0IgdGhpbmdzIGluIHRoZSBzYW1lIHBy b3BlcnR5IHNlZW1zCndlaXJkLiBJIHdvdWxkIGp1c3QgZ28gd2l0aCBzb21ldGhpbmcgdmVyeSBz aW1wbGUgbGlrZToKCllDQkNSX1RPX1JHQl9DU0M6CiogQlQuNjAxCiogQlQuNzA5CiogY3VzdG9t IG1hdHJpeAoKQW5kIHRyeWluZyB0byB1c2UgdGhlIHNhbWUgdGhpbmcgZm9yIHRoZSBjcnRjIHN0 dWZmIGlzIHByb2JhYmx5IG5vdApnb2luZyB0byBlbmQgd2VsbC4gTGlrZSBEYW5pZWwgc2FpZCB3 ZSBhbHJlYWR5IGhhdmUgdGhlCidCcm9hZGNhc3QgUkdCJyBwcm9wZXJ0eSBtdWRkeWluZyB0aGUg d2F0ZXJzIHRoZXJlLCBhbmQgdGhhdCBzdHVmZgphbHNvIHRpZXMgaW4gd2l0aCB3aGF0IGNvbG9y c3BhY2Ugd2Ugc2lnbmFsIHRvIHRoZSBzaW5rIHZpYQppbmZvZnJhbWVzL3doYXRldmVyIHRoZSBE UCB0aGluZyB3YXMgY2FsbGVkLiBTbyBteSBndXQgZmVlbGluZyBpcwp0aGF0IHRyeWluZyB0byB1 c2UgdGhlIHNhbWUgcHJvcGVydHkgZXZlcnl3aGVyZSB3aWxsIGp1c3QgZW5kIHVwCm1lc3N5LgoK LS0gClZpbGxlIFN5cmrDpGzDpApJbnRlbCBPVEMKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlz dHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4v bGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga09.intel.com ([134.134.136.24]:61535 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753234AbdA3Nf7 (ORCPT ); Mon, 30 Jan 2017 08:35:59 -0500 Date: Mon, 30 Jan 2017 15:35:13 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Brian Starkey Cc: 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: <20170130133513.GO31595@intel.com> References: <20170127172324.GB12018@e106950-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170127172324.GB12018@e106950-lin.cambridge.arm.com> Sender: linux-media-owner@vger.kernel.org List-ID: 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 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. -- Ville Syrjälä Intel OTC