@@ -573,7 +573,6 @@ void edid_state::print_standard_timing(const char *prefix, unsigned char b1, uns
break;
}
vact = (double)hact * vratio / hratio;
- vact = 8 * ((vact + 7) / 8);
refresh = (b2 & 0x3f) + 60;
formula.hact = hact;
@@ -605,6 +604,10 @@ void edid_state::print_standard_timing(const char *prefix, unsigned char b1, uns
min_vert_freq_hz = min(min_vert_freq_hz, refresh);
max_vert_freq_hz = max(max_vert_freq_hz, refresh);
}
+
+ // See Ref. D-8 in the EDID-1.4 spec
+ if (vact & 1)
+ warn("Standard Timing %ux%u has a dubious odd vertical resolution.\n", hact, vact);
}
void edid_state::detailed_display_range_limits(const unsigned char *x)
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> --- parse-base-block.cpp | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)