public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ser, Simon" <simon.ser@intel.com>
To: "ville.syrjala@linux.intel.com" <ville.syrjala@linux.intel.com>
Cc: "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>
Subject: Re: [igt-dev] [PATCH i-g-t] lib/igt_edid: fix detailed pixel timing analog/digital
Date: Thu, 25 Apr 2019 12:55:50 +0000	[thread overview]
Message-ID: <6e6b6929e731c16720b91df073c93d2e0ec55282.camel@intel.com> (raw)
In-Reply-To: <20190425123128.GK1747@intel.com>

On Thu, 2019-04-25 at 15:31 +0300, Ville Syrjälä wrote:
> On Thu, Apr 25, 2019 at 03:12:00PM +0300, Simon Ser wrote:
> > The generated EDIDs were wrongly indicating that they are analog screens. Fixup
> > the detailed timings flags to advertise a digital screen instead.
> 
> This commit message is a bit confusing. The patch only touching the sync
> signal stuff, which doesn't indicate whether the video signal itself is
> analog or digital.

That's fair. A more accurate description would be:

  The generated EDIDs were containing analog pixel timings. Fix them up
  so that they appear as digital pixel timings.

> > Currently the Linux kernel seems to ignore this completely. However I'd prefer
> > to fix this anyway to make sure we don't run into issues if an EDID consumer
> > actually cares about it.
> > 
> > Signed-off-by: Simon Ser <simon.ser@intel.com>
> > Fixes: a2fd0489c87a4d647c339f98057e6a1550e0e2f5
> > ---
> >  lib/igt_edid.c |  6 +++---
> >  lib/igt_edid.h | 10 ++++++----
> >  2 files changed, 9 insertions(+), 7 deletions(-)
> > 
> > diff --git a/lib/igt_edid.c b/lib/igt_edid.c
> > index 52e66ab2..13a5b53e 100644
> > --- a/lib/igt_edid.c
> > +++ b/lib/igt_edid.c
> > @@ -110,11 +110,11 @@ void detailed_timing_set_mode(struct detailed_timing *dt, drmModeModeInfo *mode,
> >  	pt->width_height_mm_hi = (width_mm & 0xF00) >> 4
> >  				 | (height_mm & 0xF00) >> 8;
> >  
> > -	pt->misc = 0;
> > +	pt->features = EDID_PT_DIGITAL_SEPARATE;
> >  	if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > -		pt->misc |= EDID_PT_HSYNC_POSITIVE;
> > +		pt->features |= EDID_PT_HSYNC_POSITIVE;
> >  	if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > -		pt->misc |= EDID_PT_VSYNC_POSITIVE;
> > +		pt->features |= EDID_PT_VSYNC_POSITIVE;
> >  }
> >  
> >  /**
> > diff --git a/lib/igt_edid.h b/lib/igt_edid.h
> > index bbcb939a..860a8531 100644
> > --- a/lib/igt_edid.h
> > +++ b/lib/igt_edid.h
> > @@ -54,9 +54,11 @@ struct std_timing {
> >  
> >  #define EDID_PT_HSYNC_POSITIVE (1 << 1)
> >  #define EDID_PT_VSYNC_POSITIVE (1 << 2)
> > -#define EDID_PT_SEPARATE_SYNC  (3 << 3)
> > -#define EDID_PT_STEREO         (1 << 5)
> > -#define EDID_PT_INTERLACED     (1 << 7)
> > +#define EDID_PT_SEPARATE_SYNC (3 << 3)
> > +#define EDID_PT_STEREO (1 << 5)
> > +#define EDID_PT_INTERLACED (1 << 7)
> 
> Why the whitespace changes?

I don't align those. I could find a lot of different styles for
define/enum alignment in the current codebase, so I just picked the one
I'm used to.

> > +#define EDID_PT_DIGITAL_COMPOSITE (0b10 << 3)
> > +#define EDID_PT_DIGITAL_SEPARATE (0b11 << 3)
> 
> Binary literals look strange to me. Also inconsistent with
> the rest of the bit definitions, so I would not use them at
> this time.

These are used on purpose, since they aren't bitfields. EDIDs sometimes
have two or three bits values, and I think binary literals are a lot
more readable for those than hex.

> >  
> >  struct detailed_pixel_timing {
> >  	uint8_t hactive_lo;
> > @@ -74,7 +76,7 @@ struct detailed_pixel_timing {
> >  	uint8_t width_height_mm_hi;
> >  	uint8_t hborder;
> >  	uint8_t vborder;
> > -	uint8_t misc;
> > +	uint8_t features;
> 
> Why rename it? It no longer matches drm_edid.c.

I don't think sticking to drm_edid.c is a goal per se. Because IGT
needs to generate EDIDs, it will diverge from the kernel's code anyway.

The reason for the change is that "features" is a better name than
"misc" for this field. Not that it matters a lot, I can change it back.

> >  } __attribute__((packed));
> >  
> >  struct detailed_data_string {
> > -- 
> > 2.21.0
> > 
> > _______________________________________________
> > igt-dev mailing list
> > igt-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/igt-dev
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2019-04-25 12:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-25 12:12 [igt-dev] [PATCH i-g-t] lib/igt_edid: fix detailed pixel timing analog/digital Simon Ser
2019-04-25 12:31 ` Ville Syrjälä
2019-04-25 12:55   ` Ser, Simon [this message]
2019-04-25 13:14     ` Ville Syrjälä
2019-04-25 13:24       ` Ser, Simon
2019-04-25 12:59 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2019-04-25 22:31 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork

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=6e6b6929e731c16720b91df073c93d2e0ec55282.camel@intel.com \
    --to=simon.ser@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.com \
    /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