From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB Date: Mon, 16 Jan 2017 15:57:54 +0200 Message-ID: <20170116135754.GM31595@intel.com> References: <2700086a-00b9-e8c7-f502-df132fbbe2dc@synopsys.com> <20170110111601.GY31595@intel.com> <4233e877-8ca6-b3d4-e986-a2bf3e17f1e1@synopsys.com> <20170110153315.GC31595@intel.com> <20170110155244.GD31595@intel.com> <20170110172141.GG31595@intel.com> <20170111113602.GI31595@intel.com> <1a8fd854-3943-1818-1a65-4d39830bc897@synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9B1796E33E for ; Mon, 16 Jan 2017 13:57:58 +0000 (UTC) Content-Disposition: inline In-Reply-To: <1a8fd854-3943-1818-1a65-4d39830bc897@synopsys.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Jose Abreu Cc: Daniel Vetter , Carlos Palminha , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org T24gTW9uLCBKYW4gMTYsIDIwMTcgYXQgMDE6MjQ6MDFQTSArMDAwMCwgSm9zZSBBYnJldSB3cm90 ZToKPiBIaSBWaWxsZSwKPiAKPiAKPiBTb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuCj4gCj4gCj4g T24gMTEtMDEtMjAxNyAxMTozNiwgVmlsbGUgU3lyasOkbMOkIHdyb3RlOgo+ID4gT24gV2VkLCBK YW4gMTEsIDIwMTcgYXQgMTA6Mjc6MDNBTSArMDAwMCwgSm9zZSBBYnJldSB3cm90ZToKPiA+PiBI aSBWaWxsZSwKPiA+Pgo+ID4+Cj4gPj4gT24gMTAtMDEtMjAxNyAxNzoyMSwgVmlsbGUgU3lyasOk bMOkIHdyb3RlOgo+ID4+Cj4gPj4gW3NuaXBdCj4gPj4KPiA+Pj4+IEJ1dCB3ZSBhbHJlYWR5IGhh dmUgY29sb3JfZm9ybWF0cyBmaWVsZCBpbiBkcm1fZGlzcGxheV9pbmZvCj4gPj4+PiBzdHJ1Y3Qs IHJpZ2h0PyBTaG91bGRuJ3Qgd2UgaW5zdGVhZCBjcmVhdGUgZm9yIGV4YW1wbGUgYSBoZWxwZXIK PiA+Pj4+IHdoaWNoIHJldHVybnMgdGhlIGJlc3Qgb3V0cHV0IGNvbG9yc3BhY2U/IEFjY29yZGlu ZyB0byB3aGF0IHlvdQo+ID4+Pj4gc2FpZCBpdCB3b3VsZCBiZSBzb21ldGhpbmcgbGlrZToKPiA+ Pj4+Cj4gPj4+PiBpZiAoZGlzcGxheV9pbmZvLT5jb2xvcl9mb3JtYXRzICYgRFJNX0NPTE9SX0ZP Uk1BVF9ZQ0JDUjQ0NCkKPiA+Pj4+ICAgICByZXR1cm4gWUNCQ1I0NDQ7Cj4gPj4+PiBlbHNlIGlm IChkaXNwbGF5X2luZm8tPmNvbG9yX2Zvcm1hdHMgJiBEUk1fQ09MT1JfRk9STUFUX1lDQkNSNDIy KQo+ID4+Pj4gICAgIHJldHVybiBZQ0JDUjQyMjsKPiA+Pj4+IGVsc2UgaWYgKGRpc3BsYXlfaW5m by0+Y29sb3JfZm9ybWF0cyAmIERSTV9DT0xPUl9GT1JNQVRfWUNCQ1I0MjAKPiA+Pj4+ICYmIHZp Y19pc180MjApCj4gPj4+PiAgICAgcmV0dXJuIFlDQkNSNDIwOwo+ID4+Pj4gZWxzZQo+ID4+Pj4g ICAgIHJldHVybiBSR0I0NDQ7IC8qIE1hbmRhdG9yeSBieSBzcGVjICovCj4gPj4+IFBlcmhhcHMu IEJ1dCBpdCB3b3VsZCBoYXZlIHRvIGJlIG1vcmUgaW52b2x2ZWQgdGhhbiB0aGF0IHNpbmNlIHRo ZXJlCj4gPj4+IG1pZ2h0IGxpbWl0YXRpb25zIG9uIGVnLiB0aGUgbWF4IFRNRFMgY2xvY2sgaW1w b3NlZCBieSB0aGUgc291cmNlIG9yCj4gPj4+IGNhYmxlL2RvbmdsZSB3aGljaCBwcmVzdW1hYmx5 IG1pZ2h0IHJlcXVpcmUgdGhhdCB3ZSBwaWNrIDQ6MjowIG92ZXIKPiA+Pj4gNDo0OjQuCj4gPj4+ Cj4gPj4+IEl0IHdvdWxkIGFsc28gbmVlZCB0byBhY2NvdW50IHdoaWNoIGZvcm1hdHMgYXJlIGFj dHVhbGx5IHN1cHBvcnRlZCBieQo+ID4+PiB0aGUgc291cmNlLgo+ID4+Pgo+ID4+PiBJIGd1ZXNz IGZvciBicGMgaXQgd291bGQgYmUgZW5vdWdoIHRvIGp1c3QgY29uc2lkZXIgOGJwYyBpbiBzdWNo IGEKPiA+Pj4gZnVuY3Rpb24sIGFuZCB0aGVuIHRoZSBkcml2ZXIgY2FuIGJ1bXAgaXQgdXAgYWZ0 ZXJ3YXJkcyBpZiBwb3NzaWJsZS4KPiA+PiBCdXQgdGhlIG1heCB0bWRzIGNsb2NrIHdpbGwgcHJv YmFibHkgYmUgaW52b2x2ZWQgaW4gZGVlcCBjb2xvcgo+ID4+IG1vZGVzLCBhcyAyNGJwcCBoYXMg YWx3YXlzIGEgMXggZmFjdG9yIGluIGV2ZXJ5IFlDYkNyLCBleGNlcHQKPiA+PiA0OjI6MC4gU28s IHRoZSBzaW5rIGhhcyBhIG1heCB0bWRzIGJ1dCB0aGlzIGdldHMgaW50byBhY2NvdW50Cj4gPj4g d2hlbiB0aGUgdmljIGxpc3QgcHJlc2VudCBpbiB0aGUgRURJRCBpcyBidWlsdCwgYnV0IG5vdAo+ ID4+IGNvbnNpZGVyZWQgaW4gZGVlcCBjb2xvciBtb2RlcywgdW5sZXNzIHRoZSBFRElEIGlzIGJy b2tlbi4KPiA+Pgo+ID4+PiBBcyBmb3IgdGhlIFJHQiB2cy4gWUNiQ3IgcXVlc3Rpb24sIEkgZ3Vl c3Mgd2Ugc2hvdWxkIGp1c3QgcHJlZmVyIFJHQjQ0NAo+ID4+PiBmb3Igbm93LiBBbmQgZmFsbCBi YWNrIHRvIFlDYkNyIDQ6MjoyIG9yIDQ6MjowIGlmIG5lY2Vzc2FyeS4gQW5kIHRoYXQgCj4gPj4+ IGxlYXZlcyBZQ2JDciA0OjQ6NCB1bnNlZCBzaW5jZSBpdCBoYXMgdGhlIHNhbWUgcmVxdWlyZW1l bnRzIGFzIFJHQgo+ID4+PiA0OjQ6NCBhbmQgdGh1cyBkb2Vzbid0IHByb3ZpZGUgYW55IGJlbmVm aXQgYXMgc3VjaC4gV2UgY291bGQgbGF0ZXIgYWRkCj4gPj4+IGEgcHJvcGVydHkgdG8gbGV0IHRo ZSB1c2VyIGNob29zZSBiZXR3ZWVuIFJHQiB2cy4gWUNiQ3IgbW9yZSBleHBsaWNpdGx5Lgo+ID4+ Pgo+ID4+IEhtbSwgSSBhbSB0cnlpbmcgdG8gaW1wbGVtZW50IHRoaXMgYnV0IEkgYW0gZmFjaW5n IGEgZGlmZmljdWx0eToKPiA+PiBob3cgd2lsbCBJIGZhbGxiYWNrIHRvIFlDYkNyPyBSR0IgaXMg YWx3YXlzIHN1cHBvcnRlZCBhbmQgdGhlIG1heAo+ID4+IHRtZHMgb25seSBlbnRlcnMgaW4gZGVl cCBjb2xvciBtb2Rlcy4gRm9yIHJlZmVyZW5jZSBoZXJlIGlzIGEKPiA+PiBzaW1wbGUgc3RydWN0 IGkgY3JlYXRlZCB3aXRoIHRoZSBkaWZmZXJlbnQgdG1kcyBjaGFyYWN0ZXIgcmF0ZQo+ID4+IGZh Y3RvcnMgZm9yIHRoZSBkaWZmZXJlbnQgZW5jb2RpbmdzIChJIHRoaW5rIHRoZXkgYXJlIGNvcnJl Y3QsCj4gPj4gYnV0IGNyb3NzIGNoZWNrIHBsZWFzZSk6Cj4gPj4KPiA+PiAjZGVmaW5lIERSTV9D U19ERVNDKGNzLCBmLCBiKSBcCj4gPj4gICAgIC5jb2xvcnNwYWNlID0gKGNzKSwgLmZhY3Rvcl90 b19raHogPSAoZiksIC5icGMgPSAoYikKPiA+Pgo+ID4+IHN0YXRpYyBjb25zdCBzdHJ1Y3QgZHJt X21vZGVfY29sb3JzcGFjZV9kZXNjIHsKPiA+PiAgICAgdTMyIGNvbG9yc3BhY2U7Cj4gPj4gICAg IHUzMiBmYWN0b3JfdG9fa2h6Owo+ID4+ICAgICB1MzIgYnBjOwo+ID4+IH0gZHJtX21vZGVfY29s b3JzcGFjZV9mYWN0b3JzID0geyAvKiBPcmRlcmVkIGJ5IGRlc2NlbmRpbmcKPiA+PiBwcmVmZXJl bmNlICovCj4gPj4gICAgIHsgRFJNX0NTX0RFU0MoRFJNX0NPTE9SX0ZPUk1BVF9SR0I0NDQsIDIw MDAsIDQ4KSB9LAo+ID4+ICAgICB7IERSTV9DU19ERVNDKERSTV9DT0xPUl9GT1JNQVRfWUNSQ0I0 NDQsIDIwMDAsIDQ4KSB9LAo+ID4+ICAgICB7IERSTV9DU19ERVNDKERSTV9DT0xPUl9GT1JNQVRf UkdCNDQ0LCAxNTAwLCAzNikgfSwKPiA+PiAgICAgeyBEUk1fQ1NfREVTQyhEUk1fQ09MT1JfRk9S TUFUX1lDUkNCNDQ0LCAxNTAwLCAzNikgfSwKPiA+PiAgICAgeyBEUk1fQ1NfREVTQyhEUk1fQ09M T1JfRk9STUFUX1JHQjQ0NCwgMTI1MCwgMzApIH0sCj4gPj4gICAgIHsgRFJNX0NTX0RFU0MoRFJN X0NPTE9SX0ZPUk1BVF9ZQ1JDQjQ0NCwgMTI1MCwgMzApIH0sCj4gPj4gICAgIHsgRFJNX0NTX0RF U0MoRFJNX0NPTE9SX0ZPUk1BVF9SR0I0NDQsIDEwMDAsIDI0KSB9LAo+ID4+ICAgICB7IERSTV9D U19ERVNDKERSTV9DT0xPUl9GT1JNQVRfWUNSQ0I0NDQsIDEwMDAsIDI0KSB9LAo+ID4+ICAgICB7 IERSTV9DU19ERVNDKERSTV9DT0xPUl9GT1JNQVRfWUNSQ0I0MjIsIDEwMDAsIDI0KSB9LAo+ID4+ ICAgICB7IERSTV9DU19ERVNDKERSTV9DT0xPUl9GT1JNQVRfWUNSQ0I0MjIsIDEwMDAsIDMwKSB9 LAo+ID4+ICAgICB7IERSTV9DU19ERVNDKERSTV9DT0xPUl9GT1JNQVRfWUNSQ0I0MjIsIDEwMDAs IDM2KSB9LAo+ID4+ICAgICB7IERSTV9DU19ERVNDKERSTV9DT0xPUl9GT1JNQVRfWUNSQ0I0MjAs IDEwMDAsIDQ4KSB9LAo+ID4+ICAgICB7IERSTV9DU19ERVNDKERSTV9DT0xPUl9GT1JNQVRfWUNS Q0I0MjAsIDc1MCwgMzYpIH0sCj4gPj4gICAgIHsgRFJNX0NTX0RFU0MoRFJNX0NPTE9SX0ZPUk1B VF9ZQ1JDQjQyMCwgNjI1LCAzMCkgfSwKPiA+PiAgICAgeyBEUk1fQ1NfREVTQyhEUk1fQ09MT1Jf Rk9STUFUX1lDUkNCNDIwLCA1MDAsIDI0KSB9LAo+ID4+Cj4gPj4gTm90aWNlIGhvdyBZQ2JDciA0 OjQ6NCB3aWxsIG5ldmVyIGdldCBwaWNrZWQ6IGl0IGhhcyB0aGUgc2FtZQo+ID4+IGZhY3RvciBv ZiBSR0IgNDo0OjQgZm9yIGV2ZXJ5IGJwYy4gU28sIHRoZSBzaW5rIG11c3Qgc3VwcG9ydCBSR0IK PiA+PiA0OjQ6NCBhbmQgbWF5IHN1cHBvcnQgWUNiQ3IuIFdoYXQgSSBkaWRuJ3QgY2hlY2sgd2Fz IHRoYXQgaWYgaXQKPiA+PiBpcyBwb3NzaWJsZSB0byBoYXZlIHN1cHBvcnQgZm9yIGRlZXAgY29s b3IgWUNiQ3Igd2l0aG91dCBoYXZpbmcKPiA+PiBzdXBwb3J0IGZvciBkZWVwIGNvbG9yIFJHQiA0 OjQ6NC4gRG8geW91IGtub3cgaWYgdGhpcyBjYW4gaGFwcGVuPwo+ID4gSSBkb24ndCB0aGluayB0 aGF0J3MgcG9zc2libGUuIFNvIHRoZSA0OjQ6NCBSR0IgdnMuIFlDYkNyIGNob2ljZSBpcwo+ID4g cHJvYmFibHkgc29tZXRoaW5nIHdlIGhhdmUgdG8gbGVhdmUgdXAgdG8gdGhlIHVzZXIuIEFsdGhv dWdoIEkgaGF2ZQo+ID4gYSB2YWd1ZSByZWNvbGxlY3Rpb24gdGhhdCBDRUEtODYxIHNheXMgdGhh dCB5b3Ugc2hvdWxkIHByZWZlciBZQ2JDcgo+ID4gZm9yIENFIG1vZGVzIGFuZCBSR0IgZm9yIElU IG1vZGVzLiAKPiAKPiBSR0IgRnVsbCBSYW5nZSBpcyB0aGUgZGVmYXVsdCBmb3IgSVQgbW9kZXMu IEFzIGZvciBDRSBtb2RlcyBpdAo+IHNheXMgaXQgZGVwZW5kcyBvbiB2YWN0aXZlLCB3aGljaCBJ IGFtIG5vdCBxdWl0ZSB1bmRlcnN0YW5kaW5nCj4gd2h5IChwZy4gMzQsIENFQS04NjEtRikuCgpJ IHRoaW5rIHRoYXQgdmFjdGl2ZSBub3RlIGlzIGp1c3QgcmVmZXJyaW5nIHRvIHRoZSBTRC0+QlQu NjAxIGFuZApIRC0+QlQuNzA5IHJ1bGUuCgo+IAo+ID4gSWYgd2Ugd2FudCB0byBmb2xsb3cgdGhh dCBJIHRoaW5rIHdlCj4gPiB3YW50IGEgcHJvcGVydHkgc2ltaWxhciB0byB0aGUgIkJyb2FkY2Fz dCBSR0IiIHRoaW5nIHRoYXQgYWxsb3dzIHlvdSB0bwo+ID4gc2VsZWN0IGJldHdlZW4gIkF1dG9t YXRpYyIsICJSR0IiLCBhbmQgIllDYkNyIi4gTm90IHN1cmUgaWYgd2Ugc2hvdWxkCj4gPiBhbHNv IGFsbG93IHRoZSB1c2VyIHRvIGV4cGxpY2l0bHkgc2VsZWN0IHRoZSBzdWJzYW1wbGluZyBtb2Rl IGZvciBZQ2JDci4KPiAKPiBJIHRoaW5rIHdlIGNhbiBzdGFydCBieSBvbmx5IFJHQiB2cy4gWUNi Q3IgdnMuIGF1dG9tYXRpYy4KPiAKPiA+IEkgYWxzbyB0aGluayB3ZSBzaG91bGQgcHJvYmFibHkg c3RpbGwgZmFsbCBiYWNrIHRvIFlDYkNyIDQ6MjowCj4gPiBhdXRvbWFnaWNhbGx5IGV2ZW4gaWYg dGhlIHVzZXIgZXhwbGljaXRseSBhc2tlZCBmb3IgUkdCIGlmIHdlIGNhbid0Cj4gPiBsaWdodCB1 cCB0aGUgbW9kZSB3aXRoIFJHQiA0OjQ6NC4KPiA+Cj4gCj4gQWdyZWVkLiBJIHdpbGwgc3RhcnQg YnkgdGhhdCBidXQgaW4gb3JkZXIgZm9yIHRoaXMgdG8gd29yayBpbiBhCj4gcmVhbCBzY2VuYXJp byAoSSBnb3QgaXQgd29ya2luZyBieSBjaGFuZ2luZyBFRElEIG1hbnVhbGx5KSB0aGUKPiBsaXN0 IG9mIFZJQydzIG11c3QgYmUgZXhwYW5kZWQgdG8gdGhlIG5ldyBIRE1JIDIuMCBWSUMncy4gQSBw YXRjaAo+IHdhcyBzZW50IGhlcmUgYSB3aGlsZSBhZ28gKG5vdCBieSBtZSkgYW5kIEkgdGhpbmsg eW91IGNvbW1lbnRlZAo+IG9uIHRoYXQuIEkgZG9uJ3Qga25vdyB3aGF0cyB0aGUgc3RhdHVzIG9m IHRoZSBwYXRjaCBub3cgYnV0IGl0Cj4gd2Fzbid0IG1lcmdlZC4KClRoZSBuZXcgVklDcyB3ZXJl IHJldmVydGVkIGR1ZSB0byB0aGUgImV4cG9zaW5nIGFzcGVjdCByYXRpbyBhcyBtb2RlCmZsYWdz IGJyb2tlIHVzZXJzcGFjZSIgdGhpbmcuIFdoYXQgd2UgbmVlZCB0byBkbyBpcyBhZGQgdGhlIG5l dyBWSUNzCndpdGhvdXQgY2hhbmdpbmcgdGhlIHVzZXJzcGFjZSBBUEkuIEFuZCBJIGRvbid0IHNl ZSBhbnkgcmVhc29uIHdoeQp3ZSBjYW4ndCBkbyBqdXN0IHRoYXQuIEJ1dCBubyBzdWNoIHBhdGNo IGhhcyBtYXRlcmlhbGl6ZWQgQUZBSUsuCgo+IAo+IEFueXdheSwgcmVnYXJkaW5nIHRoaXMgSSB0 aGluayB3ZSBjb3VsZDoKPiAgICAgLSBSZXVzZSB0aGlzIGV4aXN0aW5nIFJGQyB3aGVyZSBpdCBj b25jZXJucyBFRElEIHBhcnNpbmcKPiAgICAgLSBBZGQgbmV3IGZsYWdzICh3aGljaCB3aWxsIG5v dCBiZSBleHBvcnRlZCB0byB1c2Vyc3BhY2UpIHRvCj4gc2lnbmFsIFlDYkNyIDQ6MjowJ29ubHkg YW5kICdhYmxlIG1vZGVzCj4gICAgIC0gQWRkIGEgaGVscGVyIGZ1bmN0aW9uIHRvIGNvbXB1dGUg YmVzdCBjb2xvcnNwYWNlIHdoaWNoIHdpbGwKPiBhbHdheXMgcmV0dXJuIFJHQiAoZm9yIG5vdykg dW5sZXNzIHRoZSBtb2RlIGlzIDQ6MjowIG9ubHkgb3IKPiB1bmxlc3MgdGhlIG1vZGUgY2FuJ3Qg dXNlIFJHQiBiZWNhdXNlIG9mIG1heCBjbG9jayBsaW1pdGF0aW9ucy4KPiAKPiBXaGF0IGRvIHlv dSB0aGluaz8KClNvdW5kcyByZWFzb25hYmxlIHRvIG1lLgoKLS0gClZpbGxlIFN5cmrDpGzDpApJ bnRlbCBPVEMKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K ZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0 dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751469AbdAPN6F (ORCPT ); Mon, 16 Jan 2017 08:58:05 -0500 Received: from mga09.intel.com ([134.134.136.24]:7384 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751212AbdAPN6E (ORCPT ); Mon, 16 Jan 2017 08:58:04 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,239,1477983600"; d="scan'208";a="31162053" Date: Mon, 16 Jan 2017 15:57:54 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Jose Abreu Cc: dri-devel@lists.freedesktop.org, Carlos Palminha , linux-kernel@vger.kernel.org, Daniel Vetter Subject: Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB Message-ID: <20170116135754.GM31595@intel.com> References: <2700086a-00b9-e8c7-f502-df132fbbe2dc@synopsys.com> <20170110111601.GY31595@intel.com> <4233e877-8ca6-b3d4-e986-a2bf3e17f1e1@synopsys.com> <20170110153315.GC31595@intel.com> <20170110155244.GD31595@intel.com> <20170110172141.GG31595@intel.com> <20170111113602.GI31595@intel.com> <1a8fd854-3943-1818-1a65-4d39830bc897@synopsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1a8fd854-3943-1818-1a65-4d39830bc897@synopsys.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 16, 2017 at 01:24:01PM +0000, Jose Abreu wrote: > Hi Ville, > > > Sorry for the late reply. > > > On 11-01-2017 11:36, Ville Syrjälä wrote: > > On Wed, Jan 11, 2017 at 10:27:03AM +0000, Jose Abreu wrote: > >> Hi Ville, > >> > >> > >> On 10-01-2017 17:21, Ville Syrjälä wrote: > >> > >> [snip] > >> > >>>> But we already have color_formats field in drm_display_info > >>>> struct, right? Shouldn't we instead create for example a helper > >>>> which returns the best output colorspace? According to what you > >>>> said it would be something like: > >>>> > >>>> if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR444) > >>>> return YCBCR444; > >>>> else if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR422) > >>>> return YCBCR422; > >>>> else if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR420 > >>>> && vic_is_420) > >>>> return YCBCR420; > >>>> else > >>>> return RGB444; /* Mandatory by spec */ > >>> Perhaps. But it would have to be more involved than that since there > >>> might limitations on eg. the max TMDS clock imposed by the source or > >>> cable/dongle which presumably might require that we pick 4:2:0 over > >>> 4:4:4. > >>> > >>> It would also need to account which formats are actually supported by > >>> the source. > >>> > >>> I guess for bpc it would be enough to just consider 8bpc in such a > >>> function, and then the driver can bump it up afterwards if possible. > >> But the max tmds clock will probably be involved in deep color > >> modes, as 24bpp has always a 1x factor in every YCbCr, except > >> 4:2:0. So, the sink has a max tmds but this gets into account > >> when the vic list present in the EDID is built, but not > >> considered in deep color modes, unless the EDID is broken. > >> > >>> As for the RGB vs. YCbCr question, I guess we should just prefer RGB444 > >>> for now. And fall back to YCbCr 4:2:2 or 4:2:0 if necessary. And that > >>> leaves YCbCr 4:4:4 unsed since it has the same requirements as RGB > >>> 4:4:4 and thus doesn't provide any benefit as such. We could later add > >>> a property to let the user choose between RGB vs. YCbCr more explicitly. > >>> > >> Hmm, I am trying to implement this but I am facing a difficulty: > >> how will I fallback to YCbCr? RGB is always supported and the max > >> tmds only enters in deep color modes. For reference here is a > >> simple struct i created with the different tmds character rate > >> factors for the different encodings (I think they are correct, > >> but cross check please): > >> > >> #define DRM_CS_DESC(cs, f, b) \ > >> .colorspace = (cs), .factor_to_khz = (f), .bpc = (b) > >> > >> static const struct drm_mode_colorspace_desc { > >> u32 colorspace; > >> u32 factor_to_khz; > >> u32 bpc; > >> } drm_mode_colorspace_factors = { /* Ordered by descending > >> preference */ > >> { DRM_CS_DESC(DRM_COLOR_FORMAT_RGB444, 2000, 48) }, > >> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB444, 2000, 48) }, > >> { DRM_CS_DESC(DRM_COLOR_FORMAT_RGB444, 1500, 36) }, > >> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB444, 1500, 36) }, > >> { DRM_CS_DESC(DRM_COLOR_FORMAT_RGB444, 1250, 30) }, > >> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB444, 1250, 30) }, > >> { DRM_CS_DESC(DRM_COLOR_FORMAT_RGB444, 1000, 24) }, > >> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB444, 1000, 24) }, > >> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB422, 1000, 24) }, > >> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB422, 1000, 30) }, > >> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB422, 1000, 36) }, > >> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB420, 1000, 48) }, > >> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB420, 750, 36) }, > >> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB420, 625, 30) }, > >> { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB420, 500, 24) }, > >> > >> Notice how YCbCr 4:4:4 will never get picked: it has the same > >> factor of RGB 4:4:4 for every bpc. So, the sink must support RGB > >> 4:4:4 and may support YCbCr. What I didn't check was that if it > >> is possible to have support for deep color YCbCr without having > >> support for deep color RGB 4:4:4. Do you know if this can happen? > > I don't think that's possible. So the 4:4:4 RGB vs. YCbCr choice is > > probably something we have to leave up to the user. Although I have > > a vague recollection that CEA-861 says that you should prefer YCbCr > > for CE modes and RGB for IT modes. > > RGB Full Range is the default for IT modes. As for CE modes it > says it depends on vactive, which I am not quite understanding > why (pg. 34, CEA-861-F). I think that vactive note is just referring to the SD->BT.601 and HD->BT.709 rule. > > > If we want to follow that I think we > > want a property similar to the "Broadcast RGB" thing that allows you to > > select between "Automatic", "RGB", and "YCbCr". Not sure if we should > > also allow the user to explicitly select the subsampling mode for YCbCr. > > I think we can start by only RGB vs. YCbCr vs. automatic. > > > I also think we should probably still fall back to YCbCr 4:2:0 > > automagically even if the user explicitly asked for RGB if we can't > > light up the mode with RGB 4:4:4. > > > > Agreed. I will start by that but in order for this to work in a > real scenario (I got it working by changing EDID manually) the > list of VIC's must be expanded to the new HDMI 2.0 VIC's. A patch > was sent here a while ago (not by me) and I think you commented > on that. I don't know whats the status of the patch now but it > wasn't merged. The new VICs were reverted due to the "exposing aspect ratio as mode flags broke userspace" thing. What we need to do is add the new VICs without changing the userspace API. And I don't see any reason why we can't do just that. But no such patch has materialized AFAIK. > > Anyway, regarding this I think we could: > - Reuse this existing RFC where it concerns EDID parsing > - Add new flags (which will not be exported to userspace) to > signal YCbCr 4:2:0'only and 'able modes > - Add a helper function to compute best colorspace which will > always return RGB (for now) unless the mode is 4:2:0 only or > unless the mode can't use RGB because of max clock limitations. > > What do you think? Sounds reasonable to me. -- Ville Syrjälä Intel OTC