| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
If specified, this will enable additional checks against the image size.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
|
|
Carefully check if the image sizes in the base and DisplayID blocks
are consistent.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
|
|
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>
|
|
--native-timings -> --native-resolution
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
|
|
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>
|
|
Support this new option added in CVT 2.0.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Increase the alignment in the timings formats to support future
timings.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
- 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>
|
|
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>
|
|
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()]
|
|
- 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>
|
|
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>
|
|
- 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>
|
|
- 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
- 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>
|
|
- 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>
|
|
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>
|
|
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 3.10.3.6 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>
|
|
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>
|
|
This one somehow got truncated.
Signed-off-by: Joe van Tunen <joevt@shaw.ca>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
|
|
Support this new DisplayID v2 data block.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
