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: Thu, 5 Jan 2017 13:46:40 +0200 Message-ID: <20170105114640.GO31595@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> 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 1437889DEA for ; Thu, 5 Jan 2017 11:46:46 +0000 (UTC) Content-Disposition: inline In-Reply-To: <9df9f649-d3e9-7fd6-3dda-1d47799f50f7@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 T24gVGh1LCBKYW4gMDUsIDIwMTcgYXQgMTA6MDc6NDVBTSArMDAwMCwgSm9zZSBBYnJldSB3cm90 ZToKPiBIaSBWaWxsZSwKPiAKPiAKPiBPbiAwNC0wMS0yMDE3IDE2OjM2LCBWaWxsZSBTeXJqw6Rs w6Qgd3JvdGU6Cj4gPiBPbiBXZWQsIEphbiAwNCwgMjAxNyBhdCAwNDoxNTowMVBNICswMDAwLCBK b3NlIEFicmV1IHdyb3RlOgo+ID4+Cj4gIAo+IFtzbmlwXQo+IAo+ID4+PiBXaHkgZG9lcyB1c2Vy c3BhY2UgbmVlZCB0byBrbm93IHRoaXM/IE15IHRoaW5raW5nIGhhcyBiZWVuIHRoYXQgdGhlCj4g Pj4+IGRyaXZlciB3b3VsZCBkbyB0aGUgcmlnaHQgdGhpbmcgYXV0b21hZ2ljYWxseS4KPiA+Pj4K PiA+Pj4gV2UgZG8gcHJvYmFibHkgd2FudCBzb21lIGtpbmQgb2Ygb3V0cHV0IGNvbG9yc3BhY2Ug cHJvcGVydHkgdG8gYWxsb3cgdGhlCj4gPj4+IHVzZXIgdG8gc2VsZWN0IGJldHdlZW4gUkdCIHZz LiBZQ2JDciBldGMuIEJ1dCBJIHRoaW5rIGV2ZW4gd2l0aCB0aGF0IHdlCj4gPj4+IHNob3VsZCBz dGlsbCBhbGxvdyB0aGUgZHJpdmVyIHRvIGF1dG9tYWdpY2FsbHkgc2VsZWN0IFlDYkNyIDQ6Mjow IG91dHB1dAo+ID4+PiBzaW5jZSB0aGF0J3MgdGhlIG9ubHkgd2F5IHRoZSBtb2RlIHdpbGwgd29y ay4KPiA+PiBJIGFncmVlLiBXaGVuIG9ubHkgNDoyOjAgaXMgc3VwcG9ydGVkIHRoZXJlIGlzIG5v IG5lZWQgdG8gZXhwb3NlCj4gPj4gdGhlIGZsYWcgdG8gdXNlcnNwYWNlLiBIb3cgc2hhbGwgdGhl biBJIHNpZ25hbCBkcml2ZXJzIGZvciB0aGlzCj4gPj4gNDoyOjAnb25seSBzYW1wbGluZyBtb2Rl Pwo+ID4+Cj4gPj4gU28sIGZvciB0aGUgcmVtYWluaW5nIG1vZGVzLCB5b3UgcHJvcG9zZSBhIG5l dyBmaWVsZCBpbiB0aGUgbW9kZQo+ID4+IHN0cnVjdHVyZSBjYWxsZWQgJ2NvbG9yc3BhY2UnIHdo aWNoIGNvbnRhaW5zIHRoZSBsaXN0IG9mCj4gPj4gc3VwcG9ydGVkIHNhbXBsaW5nIG1vZGVzIGZv ciB0aGUgZ2l2ZW4gbW9kZT8gSSB0aGluayBpdCB3b3VsZCBiZQo+ID4+IGEgbmljZSBhZGRpdGlv bi4gVGhpcyB3YXkgaWYgYSBtb2RlIHN1cHBvcnRzIG9ubHkgUkdCIHdlIG9ubHkKPiA+PiBwYXNz ZWQgUkdCIGZsYWc7IGlmIDQ6MjowIHdhcyBhbHNvIHN1cHBvcnRlZCB3ZSBwYXNzZWQgdGhlIDQ6 MjowCj4gPj4gZmxhZywgLi4uIEFuZCB0aGVuIHVzZXIgY291bGQgc2VsZWN0LiBXZSBhbHNvIGhh dmUgdG8gaW5mb3JtIHVzZXIKPiA+PiB3aGljaCBvbmUgaXMgYmVpbmcgYWN0dWFsbHkgdXNlZC4K PiA+IElJUkMgdGhlcmUgYXJlbid0IGFueSAiUkdCIG9ubHkiIG1vZGVzIG9yIGFueXRoaW5nIGxp a2UgdGhhdC4gU28KPiA+IFlDYkNyIDQ6MjowIGlzIHRoZSBzcGVjaWFsIGNhc2UgaGVyZS4gV2Ug Y291bGQganVzdCBhZGQgc29tZXRoaW5nIHRvIHRoZQo+ID4gbW9kZSBzdHJ1Y3QgZm9yIGl0LCBv ciBkbyB3ZSBhbHJlYWR5IGhhdmUgc29tZSBvdGhlciBmbGFncyB0aGluZyB0aGF0J3MKPiA+IG5v dCBleHBvc2VkIHRvIHVzZXJzcGFjZT8gQW5kIEkgZ3Vlc3MgZHJpdmVycyBzaG91bGQgYmUgYWJs ZSB0byBvcHQgaW50bwo+ID4gc3VwcG9ydGluZyB0aGVzZSA0OjI6MCBtb2RlcyBpbiBzaW1pbGFy IHdheSB0aGV5IG9wdCBpbnRvCj4gPiBpbnRlcmxhY2VkL3N0ZXJlby93aGF0ZXZlci4KPiAKPiBJ IG1lYW4sIGlmIGEgc291cmNlIEVESUQgZG9lcyBub3QgZGVjbGFyZSBzdXBwb3J0IGZvciBZQ2JD ciBtb2Rlcwo+ICg0OjI6MiBhbmQgNDo0OjQgW2kgdGhpbmsgdGhleSBoYXZlIHRvIGJlIGJvdGgg c3VwcG9ydGVkIGlmIHNpbmsKPiBzdXBwb3J0cyAhPSBSR0JdKSB0aGVuIG9ubHkgUkdCIGNhbiBi ZSB1c2VkLiBPciBpcyBhbnkgWUNiQ3IgdGhhdAo+IGlzIHByZS1yZXF1aXJlZD8gU3RpbGwsIEkg c2VlIHlvdXIgcG9pbnQuIFdoZW4gRURJRCBkZWNsYXJlcwo+IHN1cHBvcnQgZm9yIFlDYkNyIHRo ZW4gYWxsIG1vZGVzIGNhbiB1c2UgaXQsIGFuZCBub3Qgb25seSBzb21lIG9mCj4gdGhlbS4KPiAK PiBJIHRoaW5rIGZvciBzdGVyZW8gbW9kZXMgdGhlIGZsYWdzIGNhbiBiZSBvcHQgaW4vb3V0IGlu IHVzZXJzcGFjZQo+IGV4cG9zaW5nLiBUaGVyZSBpcyBhIGZ1bmN0aW9uIGNhbGxlZAo+IGRybV9t b2RlX2V4cG9zZV90b191c2Vyc3BhY2UoKSB3aGljaCBvbmx5IGV4cG9zZXMgc3RlcmVvIG1vZGVz IGlmCj4gdXNlciBhc2tzIHRvLiBXZSBjb3VsZCBkbyBzb21ldGhpbmcgc2ltaWxhciBmb3IgNDoy OjAgbW9kZXMgKG9yCj4gZXZlbiBmb3IgYWxsIHBpeGVsIGVuY29kaW5nKS4gaS5lLiBleHBvc2Ug d2hpY2ggZW5jb2RpbmcgY2FuIGJlCj4gdXNlZCBpbiBjdXJyZW50IHZpZGVvIG1vZGUuIFdoYXQg ZG8geW91IHRoaW5rPwo+IAo+IEFib3V0IGRyaXZlcnMgb3B0aW5nIGluIGZvciA0OjI6MCBtb2Rl cywgdGhlbiB5b3UgcHJvcG9zZSBhIG5ldwo+IGZpZWxkIGluIGRybV9jb25uZWN0b3IgKGNhbGxl ZCBmb3IgZXhhbXBsZSB5Y2Jjcl80MjBfYWxsb3dlZCkKPiB3aGljaCBvbmx5IGRvZXMgdGhlIHBh cnNpbmcgb2YgdGhlIDQ6MjowIG1vZGVzIGFuZCBhZGRzIHRoZW0gdG8KPiB0aGUgbGlzdCB3aGVu IHNldCB0byB0cnVlPwoKVGhpbmtpbmcgYSBiaXQgbW9yZSBhYm91dCB0aGlzLCB3ZSBkbyBoYXZl IGEgc2xpZ2h0IHByb2JsZW0gd2l0aCBub3QKZXhwb3NpbmcgdGhpcyBpbmZvcm1hdGlvbiB0byB1 c2Vyc3BhY2UuIE5hbWVseSB3ZSBjYW4ndCBhY3R1YWxseSB0ZWxsCndoZXRoZXIgYW55IHVzZXIg cHJvdmlkZWQgbW9kZSB3b3VsZCBuZWVkIHRvIG91dHB1dCBhcyA0OjI6MCBvciBub3QuCldpdGgg dGhlIG5ldyBmbGFnIHVzZXJzcGFjZSBjb3VsZCBhdCBsZWFzdCBpbmhlcml0IHRoYXQgZnJvbSB0 aGUga2VybmVsCmFuZCBwYXNzIGl0IGJhY2sgaW4uIEJ1dCBzdGlsbCwgZXhwYW5kaW5nIHRoZSB1 YXBpIGZvciBzb21ldGhpbmcgbGlrZQp0aGlzIGZlZWxzIHF1aXRlIHdyb25nIHRvIG1lLiBDYW4g d2Ugc2ltcGx5IGxvb2sgYXQgYSBwYXJ0aWN1bGFyIHVzZXIKc3VwcGxpZWQgbW9kZSBhbmQgdGVs bCB3aGV0aGVyIGl0IG5lZWRzIHRvIGJlIG91dHB1dCBhcyA0OjI6MCAoYmFzZWQKb24gZWcuIGRv dGNsb2NrKT8KCi0tIApWaWxsZSBTeXJqw6Rsw6QKSW50ZWwgT1RDCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJp LWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S970609AbdAELuk (ORCPT ); Thu, 5 Jan 2017 06:50:40 -0500 Received: from mga02.intel.com ([134.134.136.20]:31881 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752092AbdAELtt (ORCPT ); Thu, 5 Jan 2017 06:49:49 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,321,1477983600"; d="scan'208";a="26495694" Date: Thu, 5 Jan 2017 13:46:40 +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: <20170105114640.GO31595@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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9df9f649-d3e9-7fd6-3dda-1d47799f50f7@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 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)? -- Ville Syrjälä Intel OTC