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 13:16:01 +0200 Message-ID: <20170110111601.GY31595@intel.com> References: <20170104132225.GE31595@intel.com> <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> 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 CD9196E663 for ; Tue, 10 Jan 2017 11:16:05 +0000 (UTC) Content-Disposition: inline In-Reply-To: <2700086a-00b9-e8c7-f502-df132fbbe2dc@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 T24gVGh1LCBKYW4gMDUsIDIwMTcgYXQgMDI6NDY6MDZQTSArMDAwMCwgSm9zZSBBYnJldSB3cm90 ZToKPiBIaSBWaWxsZSwKPiAKPiAKPiBPbiAwNS0wMS0yMDE3IDExOjQ2LCBWaWxsZSBTeXJqw6Rs w6Qgd3JvdGU6Cj4gPiBPbiBUaHUsIEphbiAwNSwgMjAxNyBhdCAxMDowNzo0NUFNICswMDAwLCBK b3NlIEFicmV1IHdyb3RlOgo+ID4+IEhpIFZpbGxlLAo+ID4+Cj4gPj4KPiA+PiBPbiAwNC0wMS0y MDE3IDE2OjM2LCBWaWxsZSBTeXJqw6Rsw6Qgd3JvdGU6Cj4gPj4+IE9uIFdlZCwgSmFuIDA0LCAy MDE3IGF0IDA0OjE1OjAxUE0gKzAwMDAsIEpvc2UgQWJyZXUgd3JvdGU6Cj4gPj4gIAo+ID4+IFtz bmlwXQo+ID4+Cj4gPj4+Pj4gV2h5IGRvZXMgdXNlcnNwYWNlIG5lZWQgdG8ga25vdyB0aGlzPyBN eSB0aGlua2luZyBoYXMgYmVlbiB0aGF0IHRoZQo+ID4+Pj4+IGRyaXZlciB3b3VsZCBkbyB0aGUg cmlnaHQgdGhpbmcgYXV0b21hZ2ljYWxseS4KPiA+Pj4+Pgo+ID4+Pj4+IFdlIGRvIHByb2JhYmx5 IHdhbnQgc29tZSBraW5kIG9mIG91dHB1dCBjb2xvcnNwYWNlIHByb3BlcnR5IHRvIGFsbG93IHRo ZQo+ID4+Pj4+IHVzZXIgdG8gc2VsZWN0IGJldHdlZW4gUkdCIHZzLiBZQ2JDciBldGMuIEJ1dCBJ IHRoaW5rIGV2ZW4gd2l0aCB0aGF0IHdlCj4gPj4+Pj4gc2hvdWxkIHN0aWxsIGFsbG93IHRoZSBk cml2ZXIgdG8gYXV0b21hZ2ljYWxseSBzZWxlY3QgWUNiQ3IgNDoyOjAgb3V0cHV0Cj4gPj4+Pj4g c2luY2UgdGhhdCdzIHRoZSBvbmx5IHdheSB0aGUgbW9kZSB3aWxsIHdvcmsuCj4gPj4+PiBJIGFn cmVlLiBXaGVuIG9ubHkgNDoyOjAgaXMgc3VwcG9ydGVkIHRoZXJlIGlzIG5vIG5lZWQgdG8gZXhw b3NlCj4gPj4+PiB0aGUgZmxhZyB0byB1c2Vyc3BhY2UuIEhvdyBzaGFsbCB0aGVuIEkgc2lnbmFs IGRyaXZlcnMgZm9yIHRoaXMKPiA+Pj4+IDQ6MjowJ29ubHkgc2FtcGxpbmcgbW9kZT8KPiA+Pj4+ Cj4gPj4+PiBTbywgZm9yIHRoZSByZW1haW5pbmcgbW9kZXMsIHlvdSBwcm9wb3NlIGEgbmV3IGZp ZWxkIGluIHRoZSBtb2RlCj4gPj4+PiBzdHJ1Y3R1cmUgY2FsbGVkICdjb2xvcnNwYWNlJyB3aGlj aCBjb250YWlucyB0aGUgbGlzdCBvZgo+ID4+Pj4gc3VwcG9ydGVkIHNhbXBsaW5nIG1vZGVzIGZv ciB0aGUgZ2l2ZW4gbW9kZT8gSSB0aGluayBpdCB3b3VsZCBiZQo+ID4+Pj4gYSBuaWNlIGFkZGl0 aW9uLiBUaGlzIHdheSBpZiBhIG1vZGUgc3VwcG9ydHMgb25seSBSR0Igd2Ugb25seQo+ID4+Pj4g cGFzc2VkIFJHQiBmbGFnOyBpZiA0OjI6MCB3YXMgYWxzbyBzdXBwb3J0ZWQgd2UgcGFzc2VkIHRo ZSA0OjI6MAo+ID4+Pj4gZmxhZywgLi4uIEFuZCB0aGVuIHVzZXIgY291bGQgc2VsZWN0LiBXZSBh bHNvIGhhdmUgdG8gaW5mb3JtIHVzZXIKPiA+Pj4+IHdoaWNoIG9uZSBpcyBiZWluZyBhY3R1YWxs eSB1c2VkLgo+ID4+PiBJSVJDIHRoZXJlIGFyZW4ndCBhbnkgIlJHQiBvbmx5IiBtb2RlcyBvciBh bnl0aGluZyBsaWtlIHRoYXQuIFNvCj4gPj4+IFlDYkNyIDQ6MjowIGlzIHRoZSBzcGVjaWFsIGNh c2UgaGVyZS4gV2UgY291bGQganVzdCBhZGQgc29tZXRoaW5nIHRvIHRoZQo+ID4+PiBtb2RlIHN0 cnVjdCBmb3IgaXQsIG9yIGRvIHdlIGFscmVhZHkgaGF2ZSBzb21lIG90aGVyIGZsYWdzIHRoaW5n IHRoYXQncwo+ID4+PiBub3QgZXhwb3NlZCB0byB1c2Vyc3BhY2U/IEFuZCBJIGd1ZXNzIGRyaXZl cnMgc2hvdWxkIGJlIGFibGUgdG8gb3B0IGludG8KPiA+Pj4gc3VwcG9ydGluZyB0aGVzZSA0OjI6 MCBtb2RlcyBpbiBzaW1pbGFyIHdheSB0aGV5IG9wdCBpbnRvCj4gPj4+IGludGVybGFjZWQvc3Rl cmVvL3doYXRldmVyLgo+ID4+IEkgbWVhbiwgaWYgYSBzb3VyY2UgRURJRCBkb2VzIG5vdCBkZWNs YXJlIHN1cHBvcnQgZm9yIFlDYkNyIG1vZGVzCj4gPj4gKDQ6MjoyIGFuZCA0OjQ6NCBbaSB0aGlu ayB0aGV5IGhhdmUgdG8gYmUgYm90aCBzdXBwb3J0ZWQgaWYgc2luawo+ID4+IHN1cHBvcnRzICE9 IFJHQl0pIHRoZW4gb25seSBSR0IgY2FuIGJlIHVzZWQuIE9yIGlzIGFueSBZQ2JDciB0aGF0Cj4g Pj4gaXMgcHJlLXJlcXVpcmVkPyBTdGlsbCwgSSBzZWUgeW91ciBwb2ludC4gV2hlbiBFRElEIGRl Y2xhcmVzCj4gPj4gc3VwcG9ydCBmb3IgWUNiQ3IgdGhlbiBhbGwgbW9kZXMgY2FuIHVzZSBpdCwg YW5kIG5vdCBvbmx5IHNvbWUgb2YKPiA+PiB0aGVtLgo+ID4+Cj4gPj4gSSB0aGluayBmb3Igc3Rl cmVvIG1vZGVzIHRoZSBmbGFncyBjYW4gYmUgb3B0IGluL291dCBpbiB1c2Vyc3BhY2UKPiA+PiBl eHBvc2luZy4gVGhlcmUgaXMgYSBmdW5jdGlvbiBjYWxsZWQKPiA+PiBkcm1fbW9kZV9leHBvc2Vf dG9fdXNlcnNwYWNlKCkgd2hpY2ggb25seSBleHBvc2VzIHN0ZXJlbyBtb2RlcyBpZgo+ID4+IHVz ZXIgYXNrcyB0by4gV2UgY291bGQgZG8gc29tZXRoaW5nIHNpbWlsYXIgZm9yIDQ6MjowIG1vZGVz IChvcgo+ID4+IGV2ZW4gZm9yIGFsbCBwaXhlbCBlbmNvZGluZykuIGkuZS4gZXhwb3NlIHdoaWNo IGVuY29kaW5nIGNhbiBiZQo+ID4+IHVzZWQgaW4gY3VycmVudCB2aWRlbyBtb2RlLiBXaGF0IGRv IHlvdSB0aGluaz8KPiA+Pgo+ID4+IEFib3V0IGRyaXZlcnMgb3B0aW5nIGluIGZvciA0OjI6MCBt b2RlcywgdGhlbiB5b3UgcHJvcG9zZSBhIG5ldwo+ID4+IGZpZWxkIGluIGRybV9jb25uZWN0b3Ig KGNhbGxlZCBmb3IgZXhhbXBsZSB5Y2Jjcl80MjBfYWxsb3dlZCkKPiA+PiB3aGljaCBvbmx5IGRv ZXMgdGhlIHBhcnNpbmcgb2YgdGhlIDQ6MjowIG1vZGVzIGFuZCBhZGRzIHRoZW0gdG8KPiA+PiB0 aGUgbGlzdCB3aGVuIHNldCB0byB0cnVlPwo+ID4gVGhpbmtpbmcgYSBiaXQgbW9yZSBhYm91dCB0 aGlzLCB3ZSBkbyBoYXZlIGEgc2xpZ2h0IHByb2JsZW0gd2l0aCBub3QKPiA+IGV4cG9zaW5nIHRo aXMgaW5mb3JtYXRpb24gdG8gdXNlcnNwYWNlLiBOYW1lbHkgd2UgY2FuJ3QgYWN0dWFsbHkgdGVs bAo+ID4gd2hldGhlciBhbnkgdXNlciBwcm92aWRlZCBtb2RlIHdvdWxkIG5lZWQgdG8gb3V0cHV0 IGFzIDQ6MjowIG9yIG5vdC4KPiA+IFdpdGggdGhlIG5ldyBmbGFnIHVzZXJzcGFjZSBjb3VsZCBh dCBsZWFzdCBpbmhlcml0IHRoYXQgZnJvbSB0aGUga2VybmVsCj4gPiBhbmQgcGFzcyBpdCBiYWNr IGluLiBCdXQgc3RpbGwsIGV4cGFuZGluZyB0aGUgdWFwaSBmb3Igc29tZXRoaW5nIGxpa2UKPiA+ IHRoaXMgZmVlbHMgcXVpdGUgd3JvbmcgdG8gbWUuIENhbiB3ZSBzaW1wbHkgbG9vayBhdCBhIHBh cnRpY3VsYXIgdXNlcgo+ID4gc3VwcGxpZWQgbW9kZSBhbmQgdGVsbCB3aGV0aGVyIGl0IG5lZWRz IHRvIGJlIG91dHB1dCBhcyA0OjI6MCAoYmFzZWQKPiA+IG9uIGVnLiBkb3RjbG9jayk/Cj4gPgo+ IAo+IFRoZSBwaXhlbCBjbG9jayByYXRlIGlzIGhhbGYgb2YgdGhlIFRNRFMgY2hhcmFjdGVyIHJh dGUgaW4gNDoyOjAKPiAoaW4gMjQgYml0KSwgYnV0IGZvciBleGFtcGxlIGluIGRlZXAgY29sb3Ig NDggYml0IGl0IHdpbGwgYmUgdGhlCj4gc2FtZSByYXRlLiBUaGVyZSBpcyBhbHNvIGEgcmVkdWN0 aW9uIHRvIGhhbGYgb2YgaHRvdGFsLCBoYWN0aXZlLAo+IGhibGFuaywgaGZyb250LCBoc3luYyBh bmQgaGJhY2sgYnV0IEkgZG9uJ3QgdGhpbmsgaXQncyBhIGdvb2QKPiBzb2x1dGlvbiB0byBndWlk ZSB1cyBmcm9tIHRoZXJlLgoKSSB3YXMgYXNraW5nIGlmIHdlIGNhbiBsb29rIGF0IGEgc3BlY2lm aWMgbW9kZWxpbmUgYW5kIHdoZXRoZXIgd2UKY2FuIHRlbGwgZnJvbSB0aGF0IGlmIHdlIHdvdWxk IG5lZWQgdG8gb3V0cHV0IGl0IGFzIDQ6MjowLgoKPiBXaHkgZG9lcyBpdCBmZWVsIHdyb25nIHRv IHlvdQo+IGV4cGFuZGluZyB0aGUgdWFwaT8KCkJlY2F1c2UgaXQgcmVxdWlyZXMgY2hhbmdpbmcg ZXZlcnkgc2luZ2xlIHVzZXJzcGFjZSBrbXMgY2xpZW50LiBBbmQKaXQncyBub3Qgc29tZXRoaW5n IHVzZXJzcGFjZSBzaG91bGQgaGF2ZSB0byB3b3JyeSBhYm91dC4KCj4gCj4gSSB0aGluayBpdHMg aW1wb3J0YW50IHRvIHNheSB0aGF0IHRoZSBjaG9zZW4gY29sb3JzcGFjZSBjYW4KPiBpbXByb3Zl IHBlcmZvcm1hbmNlIGluIHN5c3RlbXM6IGZvciBleGFtcGxlLCBhcyBJIHNhaWQsIDQ6MjowCj4g MjQtYml0IHVzZXMgaGFsZiB0aGUgcmF0ZSB0aGF0IFJHQiAyNC1iaXQgdXNlcyBzbyB3ZSBoYXZl IGxlc3MKPiB0cmFmaWMgaW4gdGhlIGJ1cy4gSSBhbSByZWNlbnRseSB3b3JraW5nIHdpdGggYSBG UEdBIGNvbm5lY3RlZAo+IHRyb3VnaCBwY2llIGFuZCBJIGNhbiBkZWZpbml0ZWx5IHNheSB0aGF0 IHRoaXMgaXMgdHJ1ZS4gQnV0LCBhcwo+IGV4cGVjdGVkLCBsZXNzIHRyYWZmaWMgbWVhbnMgbGVz cyBxdWFsaXR5IGluIGZpbmFsIGltYWdlIHNvIGl0cwo+IG5vdCBhIG1hdHRlciBvZiBsZXR0aW5n IGtlcm5lbCBkZWNpZGUsIEkgdGhpbmsgaXRzIGEgbWF0dGVyIG9mCj4gdXNlciBjaG9vc2luZyBi ZXR3ZWVuIHBlcmZvcm1hbmNlIHZzLiBxdWFsaXR5LgoKSW1hZ2UgcXVhbGl0eSBjb250cm9sIGZv ciB1c2Vyc3BhY2UgaXMgYSBtdWNoIGJpZ2dlciB0b3BpYy4gQW5kCnNvbWV0aGluZyB3ZSBoYXZl IG5vIHJlYWwgcHJlY2VkZW50IGZvciBhdCB0aGUgbW9tZW50IChhcGFydCBmcm9tIAp1c2VyIGNo b29zaW5nIGEgZGlmZmVyZW50IGZiIHBpeGVsIGZvcm1hdCkuCgpUaGUgcGVyZm9ybWFuY2UgYXJ1 bWVudCBpcyB2ZXJ5IGhhcmR3YXJlIGRlcGVuZGVudCwgYW5kIG5vdCByZWFsbHkKYWxsIHRoYXQg cmVsZXZhbnQgSU1PLiBJZiB0aGUgdXNlciB3YW50cyB0aGUgYmlnIG1vZGUgdGhleSBlaXRoZXIK Z2V0IGl0IG9yIG5vdCBkZXBlbmRpbmcgb24gd2hldGhlciB0aGUgc3lzdGVtIGNhbiBkZWxpdmVy LgoKLS0gClZpbGxlIFN5cmrDpGzDpApJbnRlbCBPVEMKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxA bGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxt YW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754676AbdAJLQN (ORCPT ); Tue, 10 Jan 2017 06:16:13 -0500 Received: from mga07.intel.com ([134.134.136.100]:59408 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750846AbdAJLQL (ORCPT ); Tue, 10 Jan 2017 06:16:11 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,343,1477983600"; d="scan'208";a="1110483674" Date: Tue, 10 Jan 2017 13:16:01 +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: <20170110111601.GY31595@intel.com> References: <20170104132225.GE31595@intel.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2700086a-00b9-e8c7-f502-df132fbbe2dc@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 Thu, Jan 05, 2017 at 02:46:06PM +0000, Jose Abreu wrote: > Hi Ville, > > > On 05-01-2017 11:46, Ville Syrjälä wrote: > > On Thu, Jan 05, 2017 at 10:07:45AM +0000, Jose Abreu wrote: > >> Hi Ville, > >> > >> > >> On 04-01-2017 16:36, Ville Syrjälä wrote: > >>> On Wed, Jan 04, 2017 at 04:15:01PM +0000, Jose Abreu wrote: > >> > >> [snip] > >> > >>>>> Why does userspace need to know this? My thinking has been that the > >>>>> driver would do the right thing automagically. > >>>>> > >>>>> We do probably want some kind of output colorspace property to allow the > >>>>> user to select between RGB vs. YCbCr etc. But I think even with that we > >>>>> should still allow the driver to automagically select YCbCr 4:2:0 output > >>>>> since that's the only way the mode will work. > >>>> I agree. When only 4:2:0 is supported there is no need to expose > >>>> the flag to userspace. How shall then I signal drivers for this > >>>> 4:2:0'only sampling mode? > >>>> > >>>> So, for the remaining modes, you propose a new field in the mode > >>>> structure called 'colorspace' which contains the list of > >>>> supported sampling modes for the given mode? I think it would be > >>>> a nice addition. This way if a mode supports only RGB we only > >>>> passed RGB flag; if 4:2:0 was also supported we passed the 4:2:0 > >>>> flag, ... And then user could select. We also have to inform user > >>>> which one is being actually used. > >>> IIRC there aren't any "RGB only" modes or anything like that. So > >>> YCbCr 4:2:0 is the special case here. We could just add something to the > >>> mode struct for it, or do we already have some other flags thing that's > >>> not exposed to userspace? And I guess drivers should be able to opt into > >>> supporting these 4:2:0 modes in similar way they opt into > >>> interlaced/stereo/whatever. > >> I mean, if a source EDID does not declare support for YCbCr modes > >> (4:2:2 and 4:4:4 [i think they have to be both supported if sink > >> supports != RGB]) then only RGB can be used. Or is any YCbCr that > >> is pre-required? Still, I see your point. When EDID declares > >> support for YCbCr then all modes can use it, and not only some of > >> them. > >> > >> I think for stereo modes the flags can be opt in/out in userspace > >> exposing. There is a function called > >> drm_mode_expose_to_userspace() which only exposes stereo modes if > >> user asks to. We could do something similar for 4:2:0 modes (or > >> even for all pixel encoding). i.e. expose which encoding can be > >> used in current video mode. What do you think? > >> > >> About drivers opting in for 4:2:0 modes, then you propose a new > >> field in drm_connector (called for example ycbcr_420_allowed) > >> which only does the parsing of the 4:2:0 modes and adds them to > >> the list when set to true? > > Thinking a bit more about this, we do have a slight problem with not > > exposing this information to userspace. Namely we can't actually tell > > whether any user provided mode would need to output as 4:2:0 or not. > > With the new flag userspace could at least inherit that from the kernel > > and pass it back in. But still, expanding the uapi for something like > > this feels quite wrong to me. Can we simply look at a particular user > > supplied mode and tell whether it needs to be output as 4:2:0 (based > > on eg. dotclock)? > > > > The pixel clock rate is half of the TMDS character rate in 4:2:0 > (in 24 bit), but for example in deep color 48 bit it will be the > same rate. There is also a reduction to half of htotal, hactive, > hblank, hfront, hsync and hback but I don't think it's a good > solution to guide us from there. I was asking if we can look at a specific modeline and whether we can tell from that if we would need to output it as 4:2:0. > Why does it feel wrong to you > expanding the uapi? Because it requires changing every single userspace kms client. And it's not something userspace should have to worry about. > > I think its important to say that the chosen colorspace can > improve performance in systems: for example, as I said, 4:2:0 > 24-bit uses half the rate that RGB 24-bit uses so we have less > trafic in the bus. I am recently working with a FPGA connected > trough pcie and I can definitely say that this is true. But, as > expected, less traffic means less quality in final image so its > not a matter of letting kernel decide, I think its a matter of > user choosing between performance vs. quality. Image quality control for userspace is a much bigger topic. And something we have no real precedent for at the moment (apart from user choosing a different fb pixel format). The performance arument is very hardware dependent, and not really all that relevant IMO. If the user wants the big mode they either get it or not depending on whether the system can deliver. -- Ville Syrjälä Intel OTC