All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe van Tunen <joevt@shaw.ca>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: <linux-media@vger.kernel.org>
Subject: Re: [PATCH 05/11] edid-decode: fix standard timing vertical pixels
Date: Wed, 15 Sep 2021 11:28:27 -0700	[thread overview]
Message-ID: <C0E330D8-607E-4406-8B84-E9D760311117@shaw.ca> (raw)
In-Reply-To: <95b0735e-da3a-09d4-78fd-c36db5791912@xs4all.nl>

Good find. I agree with that warning.

On 2021-09-15, 4:10 AM, "Hans Verkuil" <hverkuil@xs4all.nl> wrote:

    On 15/09/2021 12:08, Hans Verkuil wrote:
    > On 14/09/2021 14:11, joevt wrote:
    >> 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
    >>
    >> Signed-off-by: Joe van Tunen <joevt@shaw.ca>
    >> ---
    >>  parse-base-block.cpp | 1 -
    >>  1 file changed, 1 deletion(-)
    >>
    >> diff --git a/parse-base-block.cpp b/parse-base-block.cpp
    >> index e2901a6..32d2079 100644
    >> --- a/parse-base-block.cpp
    >> +++ b/parse-base-block.cpp
    >> @@ -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);
    > 
    > I need to look closer at this. I think it was added to help with 1360x768, which without
    > this line maps to 1360x765.
    > 
    > I'll get back to you on this.

    I did some more reading on this, and appendix D of the EDID 1.4 spec
    says this (D-8):

    "If calculated aspect ratio is not 16 : 10 AR, 4 : 3 AR, 5 : 4 AR or 16 : 9 AR
     what timing description should be used?"

    "Ref.: Section 3.9 (E-EDID Standard Release A, Revision 2)
     The Standard Timings Identification code may not be used to
     identify timings which do not match one of these standard aspect
     ratios. Support for such timings must be indicated elsewhere,
     e.g., by use of a Detailed Timing Descriptor."

    So you are correct with your change, but I think it would make
    sense to add a new check:

    // See also 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);

    So that way an attempt to use ST to describe 1360x768 will result in a warning.

    Regards,

    	Hans

    > 
    > Regards,
    > 
    > 	Hans
    > 
    >>  	refresh = (b2 & 0x3f) + 60;
    >>  
    >>  	formula.hact = hact;
    >>
    > 




  reply	other threads:[~2021-09-15 18:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-14 12:11 [PATCH 00/11] edid-decode: bug fixes, additions, changes joevt
2021-09-14 12:11 ` [PATCH 01/11] edid-decode: add more example EDIDs joevt
2021-09-14 12:11 ` [PATCH 02/11] edid-decode: ignore dSYM joevt
2021-09-14 12:11 ` [PATCH 03/11] edid-decode: change install directories for macOS joevt
2021-09-15 10:06   ` Hans Verkuil
2021-09-15 15:25     ` Joe van Tunen
2021-09-14 12:11 ` [PATCH 04/11] edid-decode: add bounds checking joevt
2021-09-15 10:07   ` Hans Verkuil
2021-09-14 12:11 ` [PATCH 05/11] edid-decode: fix standard timing vertical pixels joevt
2021-09-15 10:08   ` Hans Verkuil
2021-09-15 11:10     ` Hans Verkuil
2021-09-15 18:28       ` Joe van Tunen [this message]
2021-09-14 12:11 ` [PATCH 06/11] edid-decode: linefeed before fail joevt
2021-09-14 12:11 ` [PATCH 07/11] edid-decode: always linefeed after hex_block joevt
2021-09-15 10:10   ` Hans Verkuil
2021-09-15 15:43     ` Joe van Tunen
2021-09-15 18:27       ` Joe van Tunen
2021-09-14 12:11 ` [PATCH 08/11] edid-decode: output full frequencies for 4:2:0 joevt
2021-09-14 12:11 ` [PATCH 09/11] edid-decode: allow undefined aspect ratio joevt
2021-09-14 12:11 ` [PATCH 10/11] edid-decode: add warnings to VESA VSDB joevt
2021-09-14 12:11 ` [PATCH 11/11] edid-decode: cta and displayid changes joevt
2021-09-15 13:37   ` Hans Verkuil
2021-09-16  9:15     ` Joe van Tunen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C0E330D8-607E-4406-8B84-E9D760311117@shaw.ca \
    --to=joevt@shaw.ca \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.