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: Tue, 10 Jan 2017 19:21:41 +0200 Message-ID: <20170110172141.GG31595@intel.com> References: <8528542b-27fb-096f-8e22-af1fb7d5f0a1@synopsys.com> <20170104163607.GK31595@intel.com> <9df9f649-d3e9-7fd6-3dda-1d47799f50f7@synopsys.com> <20170105114640.GO31595@intel.com> <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> 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 1D1BF6E71F for ; Tue, 10 Jan 2017 17:21:46 +0000 (UTC) Content-Disposition: inline In-Reply-To: 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 T24gVHVlLCBKYW4gMTAsIDIwMTcgYXQgMDU6MDE6MDhQTSArMDAwMCwgSm9zZSBBYnJldSB3cm90 ZToKPiBIaSBWaWxsZSwKPiAKPiAKPiBbc25pcF0KPiAKPiA+PiBBcmUgeW91IGdvaW5nIHRvIHVw ZGF0ZSBhbGwgdGhlIHVzZXJzcGFjZSBjbGllbnRzPyBFeHBvc2luZyBIRE1JIDIuMAo+ID4+IG1v ZGVzIG9ubHkgZm9yIHlvdXIgZmF2b3JpdGUgY2xpZW50IGRvZXNuJ3Qgc291bmQgbGlrZSBhIGdv b2QgcGxhbiB0bwo+ID4+IG1lLgo+ID4+Cj4gPj4gSWYgd2Ugc2ltcGx5IGNvbXB1dGUgZnJvbSBh IHNwZWNpZmljIG1vZGVsaW5lIHdoZXRoZXIgaXQgbmVlZHMgdG8gYmUKPiA+PiB0cmFuc21pdHRl ZCBhcyA0OjI6MCwgSSBzdXBwb3NlIHdlIGNvdWxkIHNpbXBseSBsb29rIGZvciBhIG1hdGNoaW5n Cj4gPj4gbW9kZSBpbiB0aGUgNDoyOjAgbW9kZS4gQnV0IHRoYXQgd291bGQgbWVhbiB0aGF0IG9u bHkgdGhlIGV4YWN0IG1vZGVzCj4gPj4gbGlzdGVkIGJ5IHRoZSBFRElEIHdpbGwgd29yaywgYW5k IG90aGVycyBtaWdodCBub3QuCj4gPiBPSywgc28gdGhlIDQ6MjowIHN1cHBvcnQgaXMgYXBwYXJl bnRseSBsaXN0ZWQgb25seSBmb3Igc3BlY2lmaWMgVklDcy4KPiAKPiBIbW0sIHRoZSBzcGVjIGlz IG5vdCB2ZXJ5IGNsZWFyLiBJdCBsaXN0cyB2aWRlbyB0aW1pbmdzIHdoaWNoIG1heQo+IGJlIHVz ZWQgd2l0aCBZQ2JDciA0OjI6MCBidXQgZG9lcyBub3QgZXhwbGljaXRseSBzYXkgdGhhdCBvbmx5 Cj4gdGhlc2UgdGltaW5ncyBjYW4gYmUgdXNlZC4gQW55d2F5LCBJIGNoZWNrZWQgd2l0aCBhIGNv bGxlYWd1ZSB3aG8KPiBoYXMgZGlyZWN0IGFjY2VzcyB0byBIRE1JIEZvcnVtIGFuZCBpbmRlZWQg b25seSBWSUMgOTYsIDk3LCAxMDEsCj4gMTAyLCAxMDYgYW5kIDEwNyBjYW4gYmUgdXNlZCB3aXRo IDQ6MjowLCBzbyB5b3UgYXJlIGNvcnJlY3QuIEhlCj4gc2FpZCB0aGF0IHRoZSBpbml0aWFsIGlu dGVudGlvbiBvZiB0aGlzIHBpeGVsIGVuY29kaW5nIHdhcyB0bwo+IGdpdmUgNjBIeiByZWZyZXNo IHJhdGUgaW4gNGsgdG8gdXNlcnMgd2hvIGhhZCBsaW1pdGVkCj4gcGVyZm9ybWFuY2UsIHNvIGl0 IHdhcyBvbmx5IGludGVuZGVkIGZvciBoaWdoZXIgcmVzb2x1dGlvbnMuCj4gCj4gPiBIZW5jZSB3 ZSB3aWxsIG5lZWQgdG8ganVzdCBnbyB0aHJvdWdoIHRob3NlIGxpc3RzIHRvIHNlZSBpZiB3ZSBj YW4KPiA+IChvciBpbiBmYWN0IG11c3QpIHVzZSA0OjI6MCBmb3IgYSBzcGVjaWZpYyB1c2VyIHNw ZWNpZmllZCBtb2RlLgo+IAo+IFdlIGRvbid0IGhhdmUgeWV0IHN1cHBvcnQgZm9yIHRoZXNlIFZJ Q3MsIHNvIHRoaXMgd2lsbCBoYXZlIHRvCj4gd2FpdCA6KAo+IAo+ID4KPiA+IEkgd291bGQgc2F5 IHRoZSBvbmx5IHNsaWdodCBxdWVzdGlvbiBtYXJrIGF0IHRoaXMgcG9pbnQgaXMgd2hldGhlciB3 ZQo+ID4gc2hvdWxkIGZhdm9yIDQ6NDo0IGF0IGxvd2VyIGJwYyBvciA0OjI6MCBhdCBoaWdoZXIg YnBjIGlmIHdlIGNhbiBjaG9vc2UKPiA+IGJldHdlZW4gdGhlIHR3by4gTXkgZmlyc3QgaW5zdGlu Y3QgaXMgdG8gZmF2b3IgdGhlIDQ6NDo0IG1vZGVzIGZvciBub3cuCj4gPiBXZSBjb3VsZCBhZGQg c29tZSBrbm9icyBsYXRlciB0byBsZXQgdGhlIHVzZXIgbWFrZSB0aGF0IGNob2ljZS4KPiAKPiBJ IGFncmVlIHRoYXQgNDo0OjQgc2hvdWxkIGJlIHByZWZlcnJlZC4KPiAKPiBbc25pcF0KPiAKPiA+ Pj4gT2suIEJ1dCBub3RlIHRoYXQgdGhlcmUgaXMgbm8gbmljZSB3YXkgdG8gZmlndXJlIHRoaXMg b3V0LiBGb3IKPiA+Pj4gZXhhbXBsZSwgZm9yIGEgZ3JhcGhpY3MgY2FyZCBpdCBhbGwgZGVwZW5k cyAoYXBhcnQgZnJvbSB0aGUKPiA+Pj4gZ3JhcGhpY3MgSFcpIG9uIHRoZSBQQ0llIGJ1cy4gSWYg dGhlIGJ1cyBpcyBub3QgZnJlZSBmb3IgZW5vdWdoCj4gPj4+IGRhdGEgcmF0ZSB0aGVuIHVzZXIg Y2FuIHJlYWNoIGJvdHRsZW5lY2tzIGFuZCBub3Qgb3V0cHV0IGF0IGJlc3QKPiA+Pj4gcGVyZm9y bWFuY2UuIElmIHdlIGdhdmUgdXNlciB0aGUgYWJpbGl0eSB0byBzd2l0Y2ggZnJvbSwgZm9yCj4g Pj4+IGV4YW1wbGUsIFJHQiB0byBZQ2JDciA0OjI6MCB0aGlzIGJvdHRsZW5lY2sgY291bGQgYmUg ZWxpbWluYXRlZC4KPiA+PiBVc2Vyc3BhY2Ugd29uJ3Qga25vdyBhbnl0aGluZyBhYm91dCBzdWNo IGJvdHRsZW5lY2tzLiBUaGUga2VybmVsCj4gPj4gY2FuIGtub3cgaXQgYW5kIGhlbmNlIHNob3Vs ZCBhdXRvbWFnaWNhbGx5IGRyb3AgaW50byA0OjI6MCBtb2RlCj4gPj4gaWYgbmVjZXNzYXJ5Lgo+ ID4+Cj4gPj4+IFVubGVzcyBvZiBjb3Vyc2Ugd2UgYWx3YXlzIHByZWZlciBZQ2JDciA0OjI6MCwg d2hlbiBwb3NzaWJsZS4gSQo+ID4+PiBkaWQgdGhpcyBpbnRlcm5hbGx5IGZvciBicmlkZ2UgZHJp dmVyIGR3LWhkbWkuIFdlIGFsd2F5cyBwcmVmZXIKPiA+Pj4gWUNiQ3Igb3ZlciBSR0Igd2hlbiB0 aGV5IGFyZSBhdmFpbGFibGUuIEl0IGlzIHVzZXIgdHJhbnNwYXJlbnQgYXMKPiA+Pj4gdGhlIGNv bnRyb2xsZXIgZG9lcyB0aGUgbmVjZXNzYXJ5IGNvbG9yIHNwYWNlIGNvbnZlcnNpb24sIHRob3Vn aCwKPiA+Pj4gbm90IGlkZWFsIGluIG15IG9waW5pb24uCj4gPj4gTXkgaWRlYSB3YXMgdGhhdCB3 ZSdkIGhhdmUgYSBwcm9wZXJ0eSBmb3IgdGhlIG91dHB1dCBjb2xvcnNwYWNlIGFuZAo+ID4+IHdv dWxkIHBlcmhhcHMgZGVmYXVsdCB0byBZQ2JDciBmb3IgdGhlIENFQSBtb2RlcyAoYXMgcGVyIENF QS04NjEpLgo+ID4+IFRob3VnaCBJJ20gc3VyZSBzb21lIHBlb3BsZSB3b3VsZCBjcnkgYWJvdXQg dGhhdCBiZWhhdmlvdXIgYXMgd2VsbC4KPiA+PiBCdXQgZm9yIHRoZSBjYXNlcyB3aGVyZSB0aGVy ZSBpcyBubyBjaG9pY2UgYnV0IHRvIHVzZSBhIHNwZWNpZmljCj4gPj4gb3V0cHV0IGNvbG9yc3Bh Y2UsIHRoZSBrZXJuZWwgc2hvdWxkIGp1c3QgZG8gaXQgYXV0b21hZ2ljYWxseSBJTU8uIE5vCj4g Pj4gcG9pbnQgaW4gbWFua2luZyBsaWZlIGRpZmZjdWx0IGZvciB1c2Vyc3BhY2UuCj4gCj4gQnV0 IHdlIGFscmVhZHkgaGF2ZSBjb2xvcl9mb3JtYXRzIGZpZWxkIGluIGRybV9kaXNwbGF5X2luZm8K PiBzdHJ1Y3QsIHJpZ2h0PyBTaG91bGRuJ3Qgd2UgaW5zdGVhZCBjcmVhdGUgZm9yIGV4YW1wbGUg YSBoZWxwZXIKPiB3aGljaCByZXR1cm5zIHRoZSBiZXN0IG91dHB1dCBjb2xvcnNwYWNlPyBBY2Nv cmRpbmcgdG8gd2hhdCB5b3UKPiBzYWlkIGl0IHdvdWxkIGJlIHNvbWV0aGluZyBsaWtlOgo+IAo+ IGlmIChkaXNwbGF5X2luZm8tPmNvbG9yX2Zvcm1hdHMgJiBEUk1fQ09MT1JfRk9STUFUX1lDQkNS NDQ0KQo+ICAgICByZXR1cm4gWUNCQ1I0NDQ7Cj4gZWxzZSBpZiAoZGlzcGxheV9pbmZvLT5jb2xv cl9mb3JtYXRzICYgRFJNX0NPTE9SX0ZPUk1BVF9ZQ0JDUjQyMikKPiAgICAgcmV0dXJuIFlDQkNS NDIyOwo+IGVsc2UgaWYgKGRpc3BsYXlfaW5mby0+Y29sb3JfZm9ybWF0cyAmIERSTV9DT0xPUl9G T1JNQVRfWUNCQ1I0MjAKPiAmJiB2aWNfaXNfNDIwKQo+ICAgICByZXR1cm4gWUNCQ1I0MjA7Cj4g ZWxzZQo+ICAgICByZXR1cm4gUkdCNDQ0OyAvKiBNYW5kYXRvcnkgYnkgc3BlYyAqLwoKUGVyaGFw cy4gQnV0IGl0IHdvdWxkIGhhdmUgdG8gYmUgbW9yZSBpbnZvbHZlZCB0aGFuIHRoYXQgc2luY2Ug dGhlcmUKbWlnaHQgbGltaXRhdGlvbnMgb24gZWcuIHRoZSBtYXggVE1EUyBjbG9jayBpbXBvc2Vk IGJ5IHRoZSBzb3VyY2Ugb3IKY2FibGUvZG9uZ2xlIHdoaWNoIHByZXN1bWFibHkgbWlnaHQgcmVx dWlyZSB0aGF0IHdlIHBpY2sgNDoyOjAgb3Zlcgo0OjQ6NC4KCkl0IHdvdWxkIGFsc28gbmVlZCB0 byBhY2NvdW50IHdoaWNoIGZvcm1hdHMgYXJlIGFjdHVhbGx5IHN1cHBvcnRlZCBieQp0aGUgc291 cmNlLgoKSSBndWVzcyBmb3IgYnBjIGl0IHdvdWxkIGJlIGVub3VnaCB0byBqdXN0IGNvbnNpZGVy IDhicGMgaW4gc3VjaCBhCmZ1bmN0aW9uLCBhbmQgdGhlbiB0aGUgZHJpdmVyIGNhbiBidW1wIGl0 IHVwIGFmdGVyd2FyZHMgaWYgcG9zc2libGUuCgpBcyBmb3IgdGhlIFJHQiB2cy4gWUNiQ3IgcXVl c3Rpb24sIEkgZ3Vlc3Mgd2Ugc2hvdWxkIGp1c3QgcHJlZmVyIFJHQjQ0NApmb3Igbm93LiBBbmQg ZmFsbCBiYWNrIHRvIFlDYkNyIDQ6MjoyIG9yIDQ6MjowIGlmIG5lY2Vzc2FyeS4gQW5kIHRoYXQg CmxlYXZlcyBZQ2JDciA0OjQ6NCB1bnNlZCBzaW5jZSBpdCBoYXMgdGhlIHNhbWUgcmVxdWlyZW1l bnRzIGFzIFJHQgo0OjQ6NCBhbmQgdGh1cyBkb2Vzbid0IHByb3ZpZGUgYW55IGJlbmVmaXQgYXMg c3VjaC4gV2UgY291bGQgbGF0ZXIgYWRkCmEgcHJvcGVydHkgdG8gbGV0IHRoZSB1c2VyIGNob29z ZSBiZXR3ZWVuIFJHQiB2cy4gWUNiQ3IgbW9yZSBleHBsaWNpdGx5LgoKLS0gClZpbGxlIFN5cmrD pGzDpApJbnRlbCBPVEMKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Au b3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRl dmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162037AbdAJRV6 (ORCPT ); Tue, 10 Jan 2017 12:21:58 -0500 Received: from mga07.intel.com ([134.134.136.100]:64734 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760402AbdAJRVz (ORCPT ); Tue, 10 Jan 2017 12:21:55 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,344,1477983600"; d="scan'208";a="28631370" Date: Tue, 10 Jan 2017 19:21:41 +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: <20170110172141.GG31595@intel.com> References: <8528542b-27fb-096f-8e22-af1fb7d5f0a1@synopsys.com> <20170104163607.GK31595@intel.com> <9df9f649-d3e9-7fd6-3dda-1d47799f50f7@synopsys.com> <20170105114640.GO31595@intel.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 Tue, Jan 10, 2017 at 05:01:08PM +0000, Jose Abreu wrote: > Hi Ville, > > > [snip] > > >> Are you going to update all the userspace clients? Exposing HDMI 2.0 > >> modes only for your favorite client doesn't sound like a good plan to > >> me. > >> > >> If we simply compute from a specific modeline whether it needs to be > >> transmitted as 4:2:0, I suppose we could simply look for a matching > >> mode in the 4:2:0 mode. But that would mean that only the exact modes > >> listed by the EDID will work, and others might not. > > OK, so the 4:2:0 support is apparently listed only for specific VICs. > > Hmm, the spec is not very clear. It lists video timings which may > be used with YCbCr 4:2:0 but does not explicitly say that only > these timings can be used. Anyway, I checked with a colleague who > has direct access to HDMI Forum and indeed only VIC 96, 97, 101, > 102, 106 and 107 can be used with 4:2:0, so you are correct. He > said that the initial intention of this pixel encoding was to > give 60Hz refresh rate in 4k to users who had limited > performance, so it was only intended for higher resolutions. > > > Hence we will need to just go through those lists to see if we can > > (or in fact must) use 4:2:0 for a specific user specified mode. > > We don't have yet support for these VICs, so this will have to > wait :( > > > > > I would say the only slight question mark at this point is whether we > > should favor 4:4:4 at lower bpc or 4:2:0 at higher bpc if we can choose > > between the two. My first instinct is to favor the 4:4:4 modes for now. > > We could add some knobs later to let the user make that choice. > > I agree that 4:4:4 should be preferred. > > [snip] > > >>> Ok. But note that there is no nice way to figure this out. For > >>> example, for a graphics card it all depends (apart from the > >>> graphics HW) on the PCIe bus. If the bus is not free for enough > >>> data rate then user can reach bottlenecks and not output at best > >>> performance. If we gave user the ability to switch from, for > >>> example, RGB to YCbCr 4:2:0 this bottleneck could be eliminated. > >> Userspace won't know anything about such bottlenecks. The kernel > >> can know it and hence should automagically drop into 4:2:0 mode > >> if necessary. > >> > >>> Unless of course we always prefer YCbCr 4:2:0, when possible. I > >>> did this internally for bridge driver dw-hdmi. We always prefer > >>> YCbCr over RGB when they are available. It is user transparent as > >>> the controller does the necessary color space conversion, though, > >>> not ideal in my opinion. > >> My idea was that we'd have a property for the output colorspace and > >> would perhaps default to YCbCr for the CEA modes (as per CEA-861). > >> Though I'm sure some people would cry about that behaviour as well. > >> But for the cases where there is no choice but to use a specific > >> output colorspace, the kernel should just do it automagically IMO. No > >> point in manking life diffcult for userspace. > > 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. 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. -- Ville Syrjälä Intel OTC