From patchwork Tue Sep 28 10:38:33 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: joevt X-Patchwork-Id: 12522301 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D6F6C433F5 for ; Tue, 28 Sep 2021 10:38:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E76DD61130 for ; Tue, 28 Sep 2021 10:38:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240188AbhI1KkR (ORCPT ); Tue, 28 Sep 2021 06:40:17 -0400 Received: from omta001.cacentral1.a.cloudfilter.net ([3.97.99.32]:49628 "EHLO omta001.cacentral1.a.cloudfilter.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239952AbhI1KkQ (ORCPT ); Tue, 28 Sep 2021 06:40:16 -0400 Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id UwjamiW1PczbLVAVQmcz2A; Tue, 28 Sep 2021 10:38:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=shaw.ca; s=s20180605; t=1632825516; bh=iu0ji+WZqDZGMJRbTP58OFwkH4GHUlnMblbiEcqDTEU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=sl5jwPdgCtF+uUiRFGIGz4SgcsJY4i/FNas2DST0uTmeoQJ0khpJFw1BAsv7M7s/9 ddxVTAmLL6P5E607M6UayKoDUFx12DWEkgedQS2hyUMDaKg9wRyBwP/OxV9PXvOi83 vcv/ubhFSNP1LhcFlfKJvWb86aUxfhYSJSOb1e/BPXemhjGHZjinU8EoOOmhSxbhi6 0Hy3J68JDnYF99d6vDQptyqOmTJzE4tX/upfxaKuRlTEJ5/K0p75yHImahNLVfO4FO bWqFt9WJrOCD/dCcN4n2lYGXOdvcWw3iNny0PyusxZzF7XltAtrmJrvjasc1qUd3Dd 6HOEKDcJq+syQ== Received: from shaw.ca ([70.71.78.228]) by cmsmtp with ESMTPA id VAVOm7MUwdCHGVAVQmF4AT; Tue, 28 Sep 2021 10:38:36 +0000 Authentication-Results: ; auth=pass (LOGIN) smtp.auth=joevt@shaw.ca X-Authority-Analysis: v=2.4 cv=SdyUytdu c=1 sm=1 tr=0 ts=6152f0ac a=qDatE6m/3wxSEG8Wq7h0zQ==:117 a=qDatE6m/3wxSEG8Wq7h0zQ==:17 a=_Dj-zB-qAAAA:8 a=dw0t6H4-AAAA:8 a=J-2bKtNIKPRUydmmaZAA:9 a=c-cOe7UV8MviEfHuAVEQ:22 a=wVJa4CU9-Z26yuRAZDil:22 From: joevt To: Hans Verkuil Cc: linux-media@vger.kernel.org Subject: [PATCH 1/2] edid-decode: fix pnp and oui Date: Tue, 28 Sep 2021 03:38:33 -0700 Message-Id: <20210928103834.2186-2-joevt@shaw.ca> X-Mailer: git-send-email 2.24.3 (Apple Git-128) In-Reply-To: <20210928103834.2186-1-joevt@shaw.ca> References: <20210928103834.2186-1-joevt@shaw.ca> MIME-Version: 1.0 X-CMAE-Envelope: MS4xfD9hOCLDCCWdq6RcTGDNn5bX8EDrdsMnfu+PuCP3KSGth/3oGaNVy0xGsR18tooCqQPhBw0fhuHgrb3PMNBZzM8g9+NkgU4NsGgHI4qSH5oeIChdG8+I /iLf8AWfXKJv7DykUnrUiFwxsprFiYLUAChCiCxt+/d/ueCjMEnyftb4UGlq7kvPzo+QZmJsR0vDXKPtioU21sJd460+UWxToHo= Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Changes: - In oui.h, PNP-IDs are 32-bit numbers representing 3 ASCII characters followed by a null character. The most significant byte contains the first character, for example: hex identifier 0x41505000 ('APP\0'). This way, it is not possible to match an OUI (24-bit number, bits 31-24 are zero) when we're trying to match a PNP and vice versa. The fact that an OUI might look like a PNP is a coincidence - only one of the interpretations is correct. oui.h currently only includes unambiguous OUIs/PNPs. It is extremely unlikely that an EDID has an OUI/PNP that matches one of those when a different vendor is meant because the other three possible interpretations don't exist in the list of known OUIs and PNPs. - For DisplayID blocks, OUIs and PNPs are assumed to be big-endian to match the DisplayID specs 1.3 and 2.0. This change causes the "Endian-ness (le) of OUI is different than expected (be)." message to appear for Apple VSDB because Apple includes their OUI as little endian even though the same EDID may have a VESA VSDB in the correct big endian format. Maybe this message shouldn't happen for DisplayID tags from the 1.3 spec since they are expected to use PNP and we already output the message "Expected PNP ID but found OUI." We don't check reverse byte order interpretation of PNPs so the bigendian parameter could be ignored in the 1.3 spec cases. - In data_block_oui, matched_ascii can only be true if we find the name using a PNP. Currently in oui.h, we have no conflicts between the PNP list and the OUI list so an OUI match and a PNP match cannot both occur and therefore it doesn't matter that we try to match OUI first if we're actually expecting to match a PNP. Notes: - data_block_oui tries to match 3 variations (3 interpretations of the bytes): OUI in expected order, OUI in unexpected order, and PNP (big endian). - Expected order is big-endian for DisplayID blocks and little-endian for CTA blocks. - I don't think any EDIDs use PNP, no matter what DisplayID version or tag is used. The PNP code exists only because the DisplayID v1.3 spec says it uses PNPs. - There are 15 known OUIs that could be interpreted as a PNP (none of those are included in oui.h). Of those 15 only one of them, or 6 if you reverse the bytes, also exists as a known PNP (but none of those are included in oui.h). None of the four interpretations of those 6 have the same vendor name. DYC=Dycam Inc CYD=Cyclades Corporation 445943=zte corporation 435944= TNE= ENT=Enterprise Comm. & Computing Inc 544E45=Private 454E54= PFJ= JFP= 50464A=HUAWEI TECHNOLOGIES CO.,LTD 4A4650= PCH= HCP=Hitachi Computer Products Inc 504348=ThingsMatrix Inc. 484350= XEL= LEX=Lexical Ltd 58454C=Ericsson AB 4C4558= TGA= AGT=Agilent Technologies 544741=XCHENG HOLDING 414754= - There are 169 known OUIs that also have a reverse match (but none are in oui.h). 25 pairs of those do not match the same oui (their bytes are not the same in reverse). The two vendor names of a pair are never the same. 000010=SYTEK INC. 100000=Private 0000AA=XEROX CORPORATION AA0000=DIGITAL EQUIPMENT CORPORATION 0002BC=LVL 7 Systems, Inc. BC0200=Stewart Audio ... Signed-off-by: Joe van Tunen --- edid-decode.cpp | 4 +++- oui.h | 2 +- parse-displayid-block.cpp | 8 ++++---- 3 files changed, 8 insertions(+), 6 deletions(-) diff --git a/edid-decode.cpp b/edid-decode.cpp index 1fc7fce..6df328b 100644 --- a/edid-decode.cpp +++ b/edid-decode.cpp @@ -706,9 +706,11 @@ void edid_state::data_block_oui(std::string block_name, const unsigned char *x, } else if (do_ascii && valid_ascii) { unsigned asciioui = (x[0] << 24) + (x[1] << 16) + (x[2] << 8); ouiname = oui_name(asciioui, ouinum); + if (ouiname) { + matched_ascii = true; + } } } - matched_ascii = do_ascii && valid_ascii && ouiname != NULL; } std::string name; diff --git a/oui.h b/oui.h index 77342ac..d4fea3c 100644 --- a/oui.h +++ b/oui.h @@ -15,6 +15,6 @@ oneoui(0xca125c, Microsoft, "Microsoft" ) oneoui(0x3a0292, VESA, "VESA" ) // https://uefi.org/pnp_id_list -oneoui(0x415050, asciiApple, "Apple" ) // 'APP\0' +oneoui(0x41505000, asciiApple, "Apple" ) // 'APP\0' #undef oneoui diff --git a/parse-displayid-block.cpp b/parse-displayid-block.cpp index d527bf2..b318766 100644 --- a/parse-displayid-block.cpp +++ b/parse-displayid-block.cpp @@ -1678,7 +1678,7 @@ unsigned edid_state::displayid_block(const unsigned version, const unsigned char // DisplayID 2.0 case 0x20: data_block_oui("Product Identification Data Block (" + utohex(tag) + ")", - x + 3, len, &ouinum, false, false, false); + x + 3, len, &ouinum, false, false, true); dooutputname = false; hasoui = true; break; @@ -1694,16 +1694,16 @@ unsigned edid_state::displayid_block(const unsigned version, const unsigned char case 0x2b: data_block = "Adaptive Sync Data Block"; break; case 0x32: data_block = "Video Timing Modes Type 10 - Formula-based Timings Data Block"; break; // 0x2a .. 0x7d RESERVED for Additional VESA-defined Data Blocks - case 0x7e: + case 0x7e: // DisplayID 2.0 data_block_oui("Vendor-Specific Data Block (" + utohex(tag) + ")", x + 3, len, &ouinum, false, false, true); dooutputname = false; hasoui = true; tag |= ouinum; break; - case 0x7f: + case 0x7f: // DisplayID 1.3 data_block_oui("Vendor-Specific Data Block (" + utohex(tag) + ")", - x + 3, len, &ouinum, false, true, false); + x + 3, len, &ouinum, false, true, true); dooutputname = false; hasoui = true; tag |= ouinum; From patchwork Tue Sep 28 10:38:34 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: joevt X-Patchwork-Id: 12522303 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 93C73C4332F for ; Tue, 28 Sep 2021 10:38:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7540061130 for ; Tue, 28 Sep 2021 10:38:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240190AbhI1KkR (ORCPT ); Tue, 28 Sep 2021 06:40:17 -0400 Received: from omta001.cacentral1.a.cloudfilter.net ([3.97.99.32]:47033 "EHLO omta001.cacentral1.a.cloudfilter.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240177AbhI1KkR (ORCPT ); Tue, 28 Sep 2021 06:40:17 -0400 Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id UwjamiW1TczbLVAVRmcz2E; Tue, 28 Sep 2021 10:38:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=shaw.ca; s=s20180605; t=1632825517; bh=THiIQYzt387+2gPJ0WXJlEE91FlNkaKVJZxVSF9I7vI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=r+OkGnuv+LIQ8G5XXLs/34ao9AlRtyPnj4zTxLQ7IkCARvhFfekGn2/vv3o5cK1La Nsrs9cu9qwIZcpRMrvm/DSgUCnQ+9CHmjTyNygltLWm6ClRrav34LSMTFkPr7Lh6Du cWmUuytllsldBRkck91GrOJkFbcasQMpHNyN+olLiZ/+AxtblkUfUGFGtVPkifMYux 2YP0zmLRBkWWX06AIuiKH1U4d2gzlQNdnmmYBIxtSB04pKLDRjPvtcyakoP2vd8FC9 jgm9CtUSxbpv6sO+tMRNo35DOFA7cl8DBhBf8WbAOtue3Ug3/5JhW86nDH5/3fZwLE 8feFw5SNeHklg== Received: from shaw.ca ([70.71.78.228]) by cmsmtp with ESMTPA id VAVOm7MUwdCHGVAVRmF4AZ; Tue, 28 Sep 2021 10:38:37 +0000 Authentication-Results: ; auth=pass (LOGIN) smtp.auth=joevt@shaw.ca X-Authority-Analysis: v=2.4 cv=SdyUytdu c=1 sm=1 tr=0 ts=6152f0ad a=qDatE6m/3wxSEG8Wq7h0zQ==:117 a=qDatE6m/3wxSEG8Wq7h0zQ==:17 a=_Dj-zB-qAAAA:8 a=V-7VWGlF9ycRYLkGX24A:9 a=c-cOe7UV8MviEfHuAVEQ:22 From: joevt To: Hans Verkuil Cc: linux-media@vger.kernel.org Subject: [PATCH 2/2] edid-decode: output correct unknown block length Date: Tue, 28 Sep 2021 03:38:34 -0700 Message-Id: <20210928103834.2186-3-joevt@shaw.ca> X-Mailer: git-send-email 2.24.3 (Apple Git-128) In-Reply-To: <20210928103834.2186-1-joevt@shaw.ca> References: <20210928103834.2186-1-joevt@shaw.ca> MIME-Version: 1.0 X-CMAE-Envelope: MS4xfLltxFs50+X+rAAaOjL03auIJnlb5XGbI/ltCgsiYvbpHEHSQq/h9OBfXYqv5uc9slJZCy2J522OHV0zMV+3hCO30DclEoMD5i+FHlpYhcRdP8plhnch bzxV5aGNAT4c7z9Ub2HCBMnByoMTWp1oJnHJUjdeb7MIjs2KzCKvCXFHlepjYF9D4PVS2pRxXZjmXbXefixwIEE+E+471u0Whfk= Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org The correct length of a DisplayID block is len. It is the number of bytes in the payload bytes (doesn't include the tag or length or revision). It may include the OUI but we don't output the OUI in hex_block, and an unknown block can't have an OUI unless there's a new DisplayID spec with a new type of block that we don't know about. The length parameter passed to displayid_block is the number of bytes that remain in a DisplayID extension block (maybe it needs to be renamed?). We pass it to displayid_block so it can handle length related errors. displayid_block handles all interpretation of the data block. The only byte we know that can be interpreted on entry is the tag byte because it is the first byte and length is at least one (according to the for loop in parse_displayid_block). The payload length byte occurs after the tag byte - it might exist beyond the limit of length. If that's the case, we can at least report the tag block type with the error, but we choose not to. Instead, we output the rest of the bytes (including the tag) as hex because it probably isn't a real block. Signed-off-by: Joe van Tunen --- parse-displayid-block.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/parse-displayid-block.cpp b/parse-displayid-block.cpp index b318766..c8cea53 100644 --- a/parse-displayid-block.cpp +++ b/parse-displayid-block.cpp @@ -1711,7 +1711,7 @@ unsigned edid_state::displayid_block(const unsigned version, const unsigned char // 0x80 RESERVED case 0x81: data_block = "CTA-861 DisplayID Data Block"; break; // 0x82 .. 0xff RESERVED - default: data_block = "Unknown DisplayID Data Block (" + utohex(tag) + ", length " + std::to_string(length) + ")"; break; + default: data_block = "Unknown DisplayID Data Block (" + utohex(tag) + ", length " + std::to_string(len) + ")"; break; } if (length < 3) {