From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [EXT] Re: [PATCH] drm: fix HDR static metadata type field numbering Date: Thu, 28 Nov 2019 13:14:18 +0200 Message-ID: <20191128111418.GP1208@intel.com> References: <1574865719-24490-1-git-send-email-laurentiu.palcu@nxp.com> <20191127151703.GJ1208@intel.com> <20191128083940.GC10251@fsr-ub1664-121> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id CD7D06E7B0 for ; Thu, 28 Nov 2019 11:14:22 +0000 (UTC) Content-Disposition: inline In-Reply-To: <20191128083940.GC10251@fsr-ub1664-121> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Laurentiu Palcu Cc: Daniel Vetter , Uma Shankar , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , dl-linux-imx List-Id: dri-devel@lists.freedesktop.org T24gVGh1LCBOb3YgMjgsIDIwMTkgYXQgMDg6Mzk6NDFBTSArMDAwMCwgTGF1cmVudGl1IFBhbGN1 IHdyb3RlOgo+IE9uIFdlZCwgTm92IDI3LCAyMDE5IGF0IDA1OjE3OjAzUE0gKzAyMDAsIFZpbGxl IFN5cmrDpGzDpCB3cm90ZToKPiA+IENhdXRpb246IEVYVCBFbWFpbAo+ID4gCj4gPiBPbiBXZWQs IE5vdiAyNywgMjAxOSBhdCAwMjo0MjozNVBNICswMDAwLCBMYXVyZW50aXUgUGFsY3Ugd3JvdGU6 Cj4gPiA+IEFjY29yZGluZyB0byBDVEEtODYxIHNwZWNpZmljYXRpb24sIEhEUiBzdGF0aWMgbWV0 YWRhdGEgZGF0YSBibG9jayBhbGxvd3MgYQo+ID4gPiBzaW5rIHRvIGluZGljYXRlIHdoaWNoIEhE UiBtZXRhZGF0YSB0eXBlcyBpdCBzdXBwb3J0cyBieSBzZXR0aW5nIHRoZSBTTV8wIHRvCj4gPiA+ IFNNXzcgYml0cy4gQ3VycmVudGx5LCBvbmx5IFN0YXRpYyBNZXRhZGF0YSBUeXBlIDEgaXMgc3Vw cG9ydGVkIGFuZCB0aGlzIGlzCj4gPiA+IGluZGljYXRlZCBieSBzZXR0aW5nIHRoZSBTTV8wIGJp dCB0byAxLgo+ID4gPgo+ID4gPiBIb3dldmVyLCB0aGUgY29ubmVjdG9yLT5oZHJfc2lua19tZXRh ZGF0YS5oZG1pX3R5cGUxLm1ldGFkYXRhX3R5cGUgaXMgYWx3YXlzCj4gPiA+IDAsIGJlY2F1c2Ug aGRyX21ldGFkYXRhX3R5cGUoKSBpbiBkcm1fZWRpZC5jIGNoZWNrcyB0aGUgd3JvbmcgYml0Lgo+ ID4gPgo+ID4gPiBUaGlzIHBhdGNoIGNvcnJlY3RzIHRoZSBIRE1JX1NUQVRJQ19NRVRBREFUQV9U WVBFMSBiaXQgcG9zaXRpb24uCj4gPiAKPiA+IFdhcyBjb25mdXNlZCBmb3IgYSB3aGlsZSB3aHkg dGhpcyBoYXMgZXZlbiBiZWVuIHdvcmtuaW5nLCBidXQgSSBndWVzcwo+ID4gdGhhdCdzIGR1ZSB0 byB1c2Vyc3BhY2UgcG9wdWxhdGluZyB0aGUgbWV0YWRhdGEgaW5mb2ZyYW1lIGJsb2IgY29ycmVj dGx5Cj4gPiBldmVuIGlmIHdlIG1pc3JlcG9ydGVkIHRoZSBtZXRhZGF0YSB0eXBlcyBpbiB0aGUg cGFyc2VkIEVESUQgbWV0YWRhdGEKPiA+IGJsb2IuCj4gPiAKPiA+IEhtbS4gQWN0dWFsbHkgb24g ZnVydGhlciBpbnNwZWN0aW9uIHRoaXMgYWxsIHNlZW1zIHRvIGJlIGRlYWQgY29kZS4gVGhlCj4g PiBvbmx5IHRoaW5nIHdlIHNlZW0gdG8gdXNlIGZyb20gdGhlIHBhcnNlZCBFRElEIG1ldGFkYXRh IHN0dWZmIGlzCj4gPiBlb3RmIGJpdG1hc2suIFdlIGNoZWNrIHRoYXQgaW4gZHJtX2hkbWlfaW5m b2ZyYW1lX3NldF9oZHJfbWV0YWRhdGEoKQo+ID4gYnV0IHdlIGRvbid0IGNoZWNrIHRoZSBtZXRh ZGF0YSB0eXBlLgo+ID4gCj4gPiBNYXliZSB3ZSBzaG91bGQganVzdCBudWtlIHRoaXMgRURJRCBw YXJzaW5nIHN0dWZmIGVudGlyZWx5PyBTZWVtcwo+ID4gcHJldHR5IG11Y2ggcG9pbnRsZXNzLgo+ IAo+IEkndmUgYmVlbiB0aGlua2luZyBhYm91dCB0aGF0IGJ1dCB3ZSBtYXkgbmVlZCB0aGUgcmVz dCBvZiB0aGUgZmllbGRzIGFzCj4gd2VsbCwgZXZlbiB0aG91Z2ggdGhleSdyZSBub3QgY3VycmVu dGx5IHVzZWQuIEknbSByZWZlcnJpbmcgdG8gc2luaydzCj4gbWluL21heCBsdW1pbmFuY2UgZGF0 YS4gU2hvdWxkbid0IHdlIGFsc28gY2hlY2sgbWluL21heCBjbGwsIGJlc2lkZXMKPiBlb3RmLCB0 byBtYWtlIHN1cmUgdGhlIHNvdXJjZSBkb2VzIG5vdCBwYXNzIGhpZ2hlci9sb3dlciBsdW1pbmFu Y2UKPiB2YWx1ZXMsIHRoYW4gdGhlIHNpbmsgc3VwcG9ydHMsIGZvciBvcHRpbWFsIGNvbnRlbnQg cmVuZGVyaW5nPwo+IAo+IEhvd2V2ZXIsIENUQS04NjEgaXMgbm90IHZlcnkgY2xlYXIgb24gaG93 IGEgc2luayBzaG91bGQgYmVoYXZlIGlmCj4gdGhlIENMTCB2YWx1ZXMgZXhjZWVkIHRoZSBhbGxv d2VkIHJhbmdlLi4uIDovIEFsc28sIGlmIHRoZSBDTEwgcmFuZ2Ugb3IKPiB0aGUgRkFMTCB2YWx1 ZXMgcGFzc2VkIGluIHRoZSBEUk0gaW5mb2ZyYW1lIGV4Y2VlZCB0aGUgc2luaydzIGFkdmVydGlz ZWQKPiBtaW4vbWF4IHZhbHVlcywgSSBndWVzcyB0aGUgc2luayBjYW5ub3QgZ28gbG93ZXIvaGln aGVyIHRoYW4gaXQgY2FuCj4gYW55d2F5LiBJbiB3aGljaCBjYXNlLCB3ZSBkb24ndCByZWFsbHkg bmVlZCB0aGUgcmVzdCBvZiB0aGUgSERSIHN0YXRpYwo+IG1ldGFkYXRhIGJsb2NrIGFuZCBudWtp bmcgdGhhdCBwYXJ0IHNob3VsZCBiZSBvay4KCkknbSB0aGlua2luZyB3ZSBzaG91bGQganVzdCBj b25jbHVkZSB0aGF0IHN1Y2ggdXNlcnNwYWNlIGlzIGEgCmJ1Z2d5IG1lc3MgYW5kIGRlc2VydmVz IHdoYXRldmVyIGl0IGdldHMuCgotLSAKVmlsbGUgU3lyasOkbMOkCkludGVsCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxp c3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNr dG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbA== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A929FC432C3 for ; Thu, 28 Nov 2019 11:14:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 789682176D for ; Thu, 28 Nov 2019 11:14:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726703AbfK1LOX (ORCPT ); Thu, 28 Nov 2019 06:14:23 -0500 Received: from mga04.intel.com ([192.55.52.120]:64243 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726191AbfK1LOX (ORCPT ); Thu, 28 Nov 2019 06:14:23 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Nov 2019 03:14:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,253,1571727600"; d="scan'208";a="221298377" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by orsmga002.jf.intel.com with SMTP; 28 Nov 2019 03:14:19 -0800 Received: by stinkbox (sSMTP sendmail emulation); Thu, 28 Nov 2019 13:14:18 +0200 Date: Thu, 28 Nov 2019 13:14:18 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Laurentiu Palcu Cc: Uma Shankar , "dri-devel@lists.freedesktop.org" , Daniel Vetter , "linux-kernel@vger.kernel.org" , dl-linux-imx Subject: Re: [EXT] Re: [PATCH] drm: fix HDR static metadata type field numbering Message-ID: <20191128111418.GP1208@intel.com> References: <1574865719-24490-1-git-send-email-laurentiu.palcu@nxp.com> <20191127151703.GJ1208@intel.com> <20191128083940.GC10251@fsr-ub1664-121> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20191128083940.GC10251@fsr-ub1664-121> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 28, 2019 at 08:39:41AM +0000, Laurentiu Palcu wrote: > On Wed, Nov 27, 2019 at 05:17:03PM +0200, Ville Syrjälä wrote: > > Caution: EXT Email > > > > On Wed, Nov 27, 2019 at 02:42:35PM +0000, Laurentiu Palcu wrote: > > > According to CTA-861 specification, HDR static metadata data block allows a > > > sink to indicate which HDR metadata types it supports by setting the SM_0 to > > > SM_7 bits. Currently, only Static Metadata Type 1 is supported and this is > > > indicated by setting the SM_0 bit to 1. > > > > > > However, the connector->hdr_sink_metadata.hdmi_type1.metadata_type is always > > > 0, because hdr_metadata_type() in drm_edid.c checks the wrong bit. > > > > > > This patch corrects the HDMI_STATIC_METADATA_TYPE1 bit position. > > > > Was confused for a while why this has even been workning, but I guess > > that's due to userspace populating the metadata infoframe blob correctly > > even if we misreported the metadata types in the parsed EDID metadata > > blob. > > > > Hmm. Actually on further inspection this all seems to be dead code. The > > only thing we seem to use from the parsed EDID metadata stuff is > > eotf bitmask. We check that in drm_hdmi_infoframe_set_hdr_metadata() > > but we don't check the metadata type. > > > > Maybe we should just nuke this EDID parsing stuff entirely? Seems > > pretty much pointless. > > I've been thinking about that but we may need the rest of the fields as > well, even though they're not currently used. I'm referring to sink's > min/max luminance data. Shouldn't we also check min/max cll, besides > eotf, to make sure the source does not pass higher/lower luminance > values, than the sink supports, for optimal content rendering? > > However, CTA-861 is not very clear on how a sink should behave if > the CLL values exceed the allowed range... :/ Also, if the CLL range or > the FALL values passed in the DRM infoframe exceed the sink's advertised > min/max values, I guess the sink cannot go lower/higher than it can > anyway. In which case, we don't really need the rest of the HDR static > metadata block and nuking that part should be ok. I'm thinking we should just conclude that such userspace is a buggy mess and deserves whatever it gets. -- Ville Syrjälä Intel