linux-media.vger.kernel.org archive mirror
 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 07/11] edid-decode: always linefeed after hex_block
Date: Wed, 15 Sep 2021 08:43:30 -0700	[thread overview]
Message-ID: <F9B610CB-8B8D-4D68-B7AB-7BABF52BBDA3@shaw.ca> (raw)
In-Reply-To: <2025be72-7f3e-b63d-51c4-33a9720f65fe@xs4all.nl>

Yes, that's ugly. I will do a search for the EDID that prompted me to make this change. Maybe it's not a problem anymore.
...
Seems like the problem I had was fixed in cta_hdr10plus. I'll do more checking and testing with other calls to hex_block.


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

    On 14/09/2021 14:11, joevt wrote:
    > hex_block should not return without printing a newline (which occurs when the length is zero). This causes a missing newline after "Application Version: 1" with cta_hdr10plus for an EDID I have.
    > Any place that calls hex_block will have the same problem if it's possible for the length to be zero.
    > 
    > In other words, a hex_block needs to have a linefeed even if it has zero length, because the caller assumes it will go to the next line as it does when the hex block is not zero length.
    > 
    > Signed-off-by: Joe van Tunen <joevt@shaw.ca>
    > ---
    >  edid-decode.cpp | 4 +++-
    >  1 file changed, 3 insertions(+), 1 deletion(-)
    > 
    > diff --git a/edid-decode.cpp b/edid-decode.cpp
    > index 2316abc..6aa93fb 100644
    > --- a/edid-decode.cpp
    > +++ b/edid-decode.cpp
    > @@ -698,8 +698,10 @@ void hex_block(const char *prefix, const unsigned char *x,
    >  {
    >  	unsigned i, j;
    >  
    > -	if (!length)
    > +	if (!length) {
    > +		printf("\n");
    >  		return;
    > +	}

    Hmm, with this change I get this:

    edid-decode -c Digital/Acer/ACR0282/B12D637C1F12 with the linuxhw database:

      Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
        Source physical address: 2.0.0.0
      Unknown CTA-861 tag 0x00, length 0

      Unknown CTA-861 tag 0x00, length 0

      Unknown CTA-861 tag 0x00, length 0

      Unknown CTA-861 tag 0x00, length 0

      Unknown CTA-861 tag 0x00, length 0

      Unknown CTA-861 tag 0x00, length 0

      Unknown CTA-861 tag 0x00, length 0

    That looks pretty ugly.

    Regards,

    	Hans

    >  
    >  	for (i = 0; i < length; i += step) {
    >  		unsigned len = min(step, length - i);
    > 




  reply	other threads:[~2021-09-15 15:43 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
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 [this message]
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=F9B610CB-8B8D-4D68-B7AB-7BABF52BBDA3@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).