AgeCommit message (Collapse)AuthorFilesLines
2021-11-07edid-decode: add --diagonal optionHEADmasterHans Verkuil3-6/+53
If specified, this will enable additional checks against the image size. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-11-07edid-decode: improve image size checksHans Verkuil3-14/+52
Carefully check if the image sizes in the base and DisplayID blocks are consistent. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-10-26edid-decode: fix wrong CTA tags for DisplayID types 7, 8 & 10Hans Verkuil1-7/+7
I took the decimal extended tag values but used them in a hex number. Correct this. Reported by Okpa YC Lin. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-10-20edid-decode: update usage messageHans Verkuil1-1/+1
--native-timings -> --native-resolution Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-10-12edid-decode: add CVT 2.0 vblank supportHans Verkuil4-9/+31
With CVT 2.0 you can select the vertical blank time as input parameter to the calculation. Range 460-705 (higher might not work). Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-10-12edid-decode: support CVT 2.0 RBv3 early-vsync optionHans Verkuil4-15/+25
Support this new option added in CVT 2.0. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-10-12edid-decode: drop CVT support for Additional Vertical Blank TimeHans Verkuil5-32/+18
This was dropped again in DisplayID 2.0 E9 and from the CVT 2.0 standard. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-10-03edid-decode: add --ntsc optionHans Verkuil2-4/+18
When this option is given any timings with vertical refresh rates that are a multiple of 6 will be shown with a reduced pixel clock (1000 / 1001) for NTSC-based video. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-10-01edid-decode: rework the -n optionHans Verkuil4-61/+183
Improve the native resolution reporting: include DisplayID native resolutions in the report, and if all the listed native resolutions are all the same, then just report that. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-10-01edid-decode: fix interlaced Vback formatHans Verkuil1-1/+1
The Vback format was changed in the previous patch, but the interlaced Vback format wasn't, this caused ugly interlaced timings reports. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-30edid-decode: support larger V/Hback, Hfreq and pixclk valuesHans Verkuil1-3/+3
Increase the alignment in the timings formats to support future timings. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-30edid-decode: split off SVR parsing into cta_print_svr()Hans Verkuil2-48/+52
This makes it easier in the future to re-use the SVR parsing and checking code. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-30edid-decode: output correct unknown block lengthjoevt1-1/+1
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 <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-30edid-decode: fix pnp and ouijoevt3-6/+8
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 <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: fix reporting PNP as a proper PNPHans Verkuil4-13/+9
The PNP for a DisplayID 1.2 data block was reported as an OUI due to incorrect logic. Fixed this. Also use big endian for the Product Identification Data Block 0x00. That's a better match with the hex identifier 0x415050 ('APP'). Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: report length for unknown data blocksHans Verkuil2-2/+2
An earlier patch dropped reporting the length of an unknown data block. Add this back since that's useful to know. Also include it for DisplayID. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: replace data_block_oHans Verkuil4-29/+50
This is a rather ugly macro with side-effects. Drop it and code it explicitly. Also add a new warning to the Makefile to detect implicit fallthroughs in switches. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: fix indentsjoevt1-115/+115
The indenting was messed up during rebase. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: add interesting EDIDjoevt1-0/+0
It contains "Audio information is present, but bit ..." message and "CTA-861 DisplayID Data Block" data block. Looks like nested blocks (CTA blocks in a DisplayID block) need more indenting. Currently, indents are mostly hardcoded so they aren't suited for nested blocks. Maybe we could add indenting using the following: - Store current indent level in edid_state. - Replace printf with printi which will print spaces for current indent level. - For changing indent, you could use indent++ to indent and indent-- to outdent. - Maybe some C++ tricks can be used to automatically outdent: - Call a function that returns an object that has a constructor that increments indent. - Then the destructor can automatically decrement indent when the scope of the object ends. - We could also add a custom indenting string (currently it's two spaces per indent, but we could make it 4 or 8 spaces, or we could make it a tab). Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: remove extra vendor fieldjoevt1-6/+0
- Since we use the data_block_oui function to get the vendor for the Production Identification Data Block, we don't need to output the vendor OUI or ID separately. data_block_oui is better because it will get the OUI's name (if it is known) and it verifies that the ID is valid ASCII (don't want to print weird control characters). Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: more OUI changesjoevt3-44/+32
Since OUI is part of the tag, we can make the following changes: - Replace cta.last_block_was_hdmi_vsdb with cta.previous_cta_tag. Instead of remembering if the last tag was HDMI VSDB, we can just always remember the last tag value and compare it to the HDMI VSDB tag value. With this change, we can clean up the HDMI VSDB case statement (remove the two lines that also exist at the end of the switch and change the return to a break. - Change found_tags from std::set to std::vector. std::vector not only remembers all the flags, but also their order so you could use it to find the number of tags or the first tag (replace block_number?) or the last tag (replace previous_cta_tag?). We could replace previous_cta_tag except found_tags is separate for DisplayID block for some reason, while previous_cta_tag is used for CTA data blocks in both CTA blocks and DisplayID blocks. Maybe there should be only one found_tags, like there is only one previous_cta_tag. - Remove duplicate parameter from cta_block. Instead, pass the list of found_tags that we want to check for duplicates. This way, the tag value doesn't need to be recalculated. - For blocks with OUI that we don't know how to parse, skip OUI even if it is zero. Make sure length passed to hex_block is not negative. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: make OUI enumjoevt5-121/+148
Instead of a 3 byte value, create an enumeration of known OUIs. This way, it can be combined with tag value to identify a data block type with a single value. This value can be used in a switch statement or other places (see later commits). - The list of known OUIs is in a new file oui.h. It contains the 3 byte value, a enum base name for the enum, and the OUI name. - The oui.h can be included in other source files for different purposes be changing the oneoui macro. It's used in edid-decode.h to define the enumeration. - Function oui_name uses oui.h to convert an OUI to the enum value. Removed the reverse parameter - OUI byte order is now handled by the caller, data_block_oui. - data_block_oui is modified to do the following: - It will return the oui enumeration. - It is made suitable for OUIs in DisplayID data blocks. - The ignorezeos flag is only true for the DisplayID "Product Identification Data Block". If the data block is zeros then it's probably not a data block so ignore it. For "Product Identification Data Block", the OUI doesn't change the interpretation of the data block so caller (displayid_block) then immediately clears the OUI enum. - The do_ascii flag is true for DisplayID v1.2 data blocks (section 4.1.1 of the DisplayID 1.3 spec says Manufacturer/Vendor ID is ASCII). - The big_endian flag is true for DisplayID v2.0 data blocks and false for CTA-861 data blocks. - It always outputs the block name first so that fails and warnings will appear after the block name instead of before. data_block_oui does the following: - It gets the OUI bytes in the order determined by the big_endian flag. An OUI is a 24 bit number. - It gets a PNP ID value (ASCII) with the same 3 bytes. A PNP ID in oui.h is a 32 bit number (3 characters [A-Z] followed by a NULL) so it cannot be confused with an OUI in the same file. - If bytes of the OUI extend beyond the end of the block then they are assumed to be zero, and it does not try to convert the OUI to a name, and the enum result is 0 which is invalid, and the PNP result is "?" which is invalid. - It tries to match the OUI. If that doesn't match then it tries to match the reversed OUI. If DisplayID v1.2 then it also tries to match PNP if the other two didn't match. - If ASCII is expected (DisplayID v1.2) and found, the output block name is "block_name, PNP ID 'ABC'". It is output with a colon as usual. - The "Unknown block_name, OUI %s." warning message is replaced by "Unknown OUI %s." (or with "Unknown OUI %s (possible PNP %s)." if ASCII is expected and %the OUI is valid ASCII). In either case, the warning is prefixed by %"block_name, OUI %s:" or "block_name, PNP ID %s:" in the warnings and %failures section. - The "Invalid length %u < 3." fail message is replaced by "Data block length (%d) is not enough to contain an OUI.". - The "OUI %s is in the wrong byte order" fail message (which is missing the trailing period) is replaced with "Endian-ness (be|le) of OUI is different than expected (le|be)." - In parse-cta-block.cpp and parse-displayid-block.cpp, in the first switch statement, any tag with an OUI has its block name output by data_block_oui so they'll set dooutputname to false to stop the block name from being output again. - In parse-displayid-block.cpp, don't include OUI in hex dump of unknown data block types. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> [hverkuil: changed fail("Expected PNP ID but found OUI.") to warn()]
2021-09-27edid-decode: DisplayID length checksjoevt1-10/+16
- Only report DisplayID version discrepancy for a data block after verifying that the data block exists and is properly sized. The fail message is output after the block name instead of before the block name. - Output hex bytes of non-zero filler when length is 1 or 2. We did the same for lengths longer than that in a previous commit. - Output hex bytes that are skipped when the block length is longer than the number of bytes remaining in the DisplayID block. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: DisplayID non-0 filler fixesjoevt1-0/+3
It's probably not a Product Identification Data Block or any kind of block so data_block should be cleared (so that the block name doesn't appear in the Failures section for this fail). Output hex data because it might contain interesting data (it's at least known to be not zero). Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: ignore DisplayID version for OUI check.joevt1-7/+4
- Interpret VESA data block even if DisplayID version is not 2.0. See example apple-xdr-6k. - Remove the "Unknown DisplayID Data Block" fail message for these tags because there's a "Use of DisplayID v#.# tag for DisplayID v%u.%u.\n" fail message for them. - Include tag number for ambiguous DisplayID tags. - Don't need tag number for 0x81 because it's not ambiguous. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: displayid_block len fixesjoevt1-14/+12
- Calculate len early like we do for CTA blocks (set to zero if there's no bytes remaining to get len). We'll use this for OUI errors later. - The return value of the displayid_block function is now the entire length of the DisplayID data block. Returning length will thus terminate the loop in parse_displayid_block, so we don't need the 0xff magic number. - Bug fix: For the "Not enough bytes remain (%d) for a DisplayID data block or the DisplayID filler is non-0.\n" fail message, if length remaining is only 1 then don't check the byte beyond that. Also change "or" to "and" in that message. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: remove offset from displayid_blockjoevt2-69/+69
Change the function so that x points to the start of the DisplayID block. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: move parse_displayid_block inner loopjoevt2-44/+54
Move it to a new function displayid_block. Then we can simplify it later. This is mostly just a copy/paste. No output should change. The new function returns 0xff for len to signal a break from the loop in parse_displayid_block. That will be cleaned up later. first_data_block is replaced with dispid.block_number (similar to cta.block_number) Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: replace first_block with block_numberjoevt2-7/+8
track progress instead of milestones. With a flag like first_block, you can only know if you're at the first block or not. But with a progressing value like block_number, you can know when you're at the first block or second block etc. and you can know how many blocks have been done. We'll also replace last_block_was_hdmi_vsdb in a later commit. Both of these changes will cleanup the hdmi block. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: move audio fail/warn messagesjoevt2-10/+7
For tag 0x711, the "Audio information is present" fail message appears before the block name. Output the block name before any fail/warning messages related to the block. For tags that are supposed to have an OUI but are not long enough: - Output the block name before the "Invalid length" fail message. The fail message should include the block name but we don't want cta_block to output data_block so clear it after the fail, before exiting. For tags with a 3 byte OUI: - Since we are calling data_block_oui early (before data_block is output in cta_block), don't output block name in data_block_oui - cta_block will do that for us. - data_block now includes the OUI (the block name in the failure/warning section will match block name in the EDID section). Probably things would be simpler if we always set data_block to the block name, then have fail/warning messages that don't include the block name so they don't look redundant in the failures/warnings sections. For example we could have something like: Unknown CTA-861 Data Block (tag 0x00): Invalid tag. Vendor-Specific Data Block, OUI $$-$$-$$: Unknown OUI. etc. Sample corrupted EDID (combination of vizio-e65e0-hdmi and /System/Library/Displays/Contents/Resources/Overrides/DisplayVendorID-593a/DisplayProductID-1018:edid-patches): 00ffffffffffff00593a181001010101001a0103808f50782a6a6da4554f9e270e474aa5ce00d1c0010101010101010101010101010104740030f2705a80b0588a0048684200001e023a801871382d40582c450048684200001e000000fc004536352d45310a202020202020000000fd00174c0f8c26000a202020202020014502035171575f645d625e631022201f2105041307060302111215160132570600000000000000000000090707150750830100006f030c002000383ca05b5b0060010000000061666065e3060f01e305e00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ea Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: change unknown CTA block namesjoevt1-21/+12
Make consistent the Unknown CTA-861 Data Block names and warnings. - Add " Data Block" suffix for normal tags (like unknown extended tags and known normal tags have). - Put tag in parenthesis (like unknown extended tags). - Output colon after unknown block name (like known tags). - Make warning same as block name (so the block mentioned in the warning section can be found more easily in the edid output). 1) Unknown normal tags: Before: - name: "Unknown CTA-861 tag 0x$$" - warning: "Unknown CTA-861 Data Block #." After: "Unknown CTA-861 Data Block (tag 0x$$):" (with period instead of colon for warning) 2) Unknown extended tags: Before: - name: "Unknown CTA-861 @Data Block (extended tag 0x$$)" (@ = "", "Video-Related ", "Audio-Related ", "HDMI-Related ") - warning: "Unknown Extended CTA-861 Data Block 0x$$." After: - "Unknown CTA-861 @Data Block (extended tag 0x$$):" (with period instead of colon for warning) We still have the following from a previous commit: 3) Truncated extended tag (when length is not enough to get the extended tag): Before: name: "Unknown CTA-861 Data Block (extended tag truncated):" failure: "Extended tag cannot have zero length." Since the name is different than the failure message, we should set data_block so both are output to the failure section: After: failure: "Unknown CTA-861 Data Block (extended tag truncated): Extended tag cannot have zero length." Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: remove cta_ext_blockjoevt2-108/+80
Since cta_ext_block is exactly like cta_block now, we can move its code (mostly without modification) to cta_block. This way it's easier to ensure that the blocks are handled consistently (order of statements, including fails, warnings, defaults, etc.) This change should not affect output. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: move unknown block warningjoevt1-44/+38
Also, make cta_block like cta_ext_block First, fix the first switch statement in cta_ext_block. The first switch statement sets or clears data_block (the name of the block which is used in the Warnings and Failures section of the output). Remove hex_block because it will be done by the third switch statement that handles outputting the contents of each block. The "Unknown Extended CTA-861 Data Block 0x%02x.\n" warning now appears after the block name instead of after the block contents (because it's not the contents that caused the error). Then, in cta_block: 1) Create a first switch statement like that of cta_ext_block (described above). The "Unknown CTA-861 Data Block %u.\n" warning now appears after the block name instead of after the block contents (because it's not the contents that caused the error). 2) Create a second switch statement like that of cta_ext_block. It handles checking for duplicate blocks. 3) After checking for duplicates, check cta_byte3 / audio_block discrepancy, exactly like cta_ext_block does. These lines come from after the original switch statement of cta_block. 4) The original switch statement of cta_block has lines that are moved to the new first and second switch statements. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: move OUI parsing to separate functionjoevt3-81/+46
Since all three occurrences of OUI parsing are the same in parse-cta-block.cpp, we can move them to a separate function in edid-decode.cpp (because we may want to use the function for non-CTA parsing as well). data_block_oui contains identical code except for the following: 1) The warning for unknown OUI name is output after the block name instead of after the block contents. Other changes that don't affect output: - oui is set to 0 if the OUI is unknown so that it can't lead to executing any known OUI code by the caller. - A macro is used to call data_block_oui. It updates x and length appropriately for the caller. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: make all OUI handlers the samejoevt1-17/+22
Because they are the same but with different block names. For Vendor-Specific Data Block there are a couple fixes: 1) If the length is not enough to contain an OUI, then a fail is output. I have a corrupted EDID that would cause 20000+ lines of hex to be output without this check. 2) The return statement for VSDB with unknown OUI is changed to a break statement. The code after the switch statement will be executed which causes the block to be considered as a first block or as not a hdmi vsdb. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: Capitalize fail sentencejoevt1-1/+1
Most fail messages are a sentence that starts with a capital letter and ends with a period. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: Output block type before failjoevt1-6/+6
For extended tags, block type should be output before fail messages (duplicate failure, or missing audio failure). For normal tags 0x04 and 0x05, fail message should appear after block type instead of block data to be consistent (and also to indicate that the failure is because of the block type and not the contents of the block). Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: extended tag length checkjoevt2-98/+114
Change: - Don't read extended tag if length of extended block is zero. Report a fail in that case. Modifications that don't change behavior but help with the above change or with changes in later commits: - Differentiate extended tags from normal tags by adding 0x700 to the extended tag byte. - Increase x after parsing each byte (the tag/length byte and the extended tag byte). Decrease length if there's an extended byte. - Change cta_ext_block so that x parameter points to byte after the extended tag. Since x points to after extended tag, pass the extended tag as a parameter. - After reading an OUI, increase x by 3 and decrease length by 3. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: Replace return with break in switchjoevt1-25/+27
Use break to leave a switch instead of return. Move code that was after switch to default statement in switch. This way, we can move switch or have other code after switch. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: Capitalize fail sentencejoevt1-2/+1
- Most fail messages are a sentence that starts with a capital letter and ends with a period. - Remove extra line. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: check cta_hdr10plus lengthjoevt1-5/+6
- if the length is 0 then it cannot get Application Version. Output a fail message. - cta_hdr10plus may output hex after "Application Version: %u". If the hex is longer than 16 characters, then more lines of hex will be output and they won't align with the first line. Instead, always start the hex on a new line. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: exclude oui from _block functionsjoevt1-24/+24
cta_hdmi_block is the only function that has oui included. Make it like all the other functions by increasing x by 3 (the size of the oui) and decreasing length by the same amount. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: fix standard timing vertical pixelsjoevt1-1/+4
Don't do ceiling to nearest 8 pixels for active vertical lines. See examples elo-4600l-hdmi and kogan-kaled24144f-hdmi. Section 3.9 and of EDID 1.4 does not say vertical lines must be a multiple of 8. This line of code appears to have been added to satisfy the 3rd example in VTB-EXT spec but that example has an incorrect HAP indicator decimal value so it cannot be trusted. Also, all 3 examples have an incorrect vertical refresh value as noted in parse-vtb-ext-block.cpp. The VESA DMT spec has the following examples that are not a multiple of 8 lines which support this change: 1400x1050 4:3 1440x900 16:10 1600x900 16:9 1680x1050 16:10 Finally, Ref. D-8 of EDID 1.4 says about Section 3.9 that "The Standard Timings Identification code may not be used to identify timings which do not match one of these standard aspect ratios." If vertical lines is odd then a warning is output. That way an attempt to use ST to describe 1360x768 (a common resolution) will result in a warning (since the nearest result that can be described by an ST is 1360x765). Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-27edid-decode: remove unnecessary length checkjoevt1-3/+0
The for loop also checks the length. Nothing will happen if length is zero as expected. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-26edid-decode: re-add vizio-m60c3-hdmi-onkyo-txnr555joevt1-0/+0
This one somehow got truncated. Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-20edid-decode: add support for DisplayID Adaptive Sync DBHans Verkuil2-0/+45
Support this new DisplayID v2 data block. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-20edid-decode: convert Dolby Vision PQ values to cd/m^2Hans Verkuil1-5/+41
Convert the Dolby Vision PQ values to cd/m^2. Since I do not have the DV spec, I made an educated guess what the divider is to map the integer PQ value to a value in the range 0-1 which is needed as input to the pq2nits function. It should be pretty close to the actual value, though. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-16edid-decode: warn if sRGB and gamma != 2.2Hans Verkuil1-1/+3
If the sRGB bit is set, but the gamma is not 2.2, then warn about that. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-15edid-decode: output full frequencies for 4:2:0joevt1-2/+4
Don't half hfreq for 4:2:0 timings - the character clock is halved, but the number of characters per line is also halved (two luminance values per character for 4:2:0), so there's no change in hfreq. Don't half pixel clock because it looks weird. Character clock is halved but the number of pixels remains the same (two luminance values per character for 4:2:0). Continue to use the half hfreq and half pixel clock for the ranges calculations because some non-HDMI 2.0 displays have max pixel clock halved when they have 4:2:0 modes and because other reasons that lead to adding this code in the first place? Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2021-09-15edid-decode: add warnings to VESA VSDBjoevt1-9/+24
Add warnings for VESA vendor specific datablock (bits that should be zero and reserved values). Signed-off-by: Joe van Tunen <joevt@shaw.ca> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

Privacy Policy