lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <87muc9kfam.fsf@intel.com>
Date:   Tue, 03 Dec 2019 10:02:25 +0200
From:   Jani Nikula <jani.nikula@...ux.intel.com>
To:     allen.chen@....com.tw
Cc:     Jau-Chih.Tseng@....com.tw, maxime.ripard@...tlin.com,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        airlied@...ux.ie, pihsun@...omium.org, sean@...rly.run
Subject: RE: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking timings logic

On Tue, 03 Dec 2019, <allen.chen@....com.tw> wrote:
> Hi Jani Nikula
>
>
>
> Thanks for your suggestion and I have replied two comments below.

Please read my question again.

BR,
Jani.

>
>
>
> -----Original Message-----
> From: Jani Nikula [mailto:jani.nikula@...ux.intel.com]
> Sent: Wednesday, November 27, 2019 6:29 PM
> To: Allen Chen (陳柏宇)
> Cc: Jau-Chih Tseng (曾昭智); Maxime Ripard; Allen Chen (陳柏宇); open list; open list:DRM DRIVERS; David Airlie; Pi-Hsun Shih; Sean Paul
> Subject: Re: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking timings logic
>
>
>
> On Tue, 26 Nov 2019, allen <allen.chen@....com.tw> wrote:
>
>> According to VESA ENHANCED EXTENDED DISPLAY IDENTIFICATION DATA STANDARD
>
>> (Defines EDID Structure Version 1, Revision 4) page: 39
>
>> How to determine whether the monitor support RB timing or not?
>
>> EDID 1.4
>
>> First:  read detailed timing descriptor and make sure byte 0 = 0x00,
>
>>     byte 1 = 0x00, byte 2 = 0x00 and byte 3 = 0xFD
>
>> Second: read EDID bit 0 in feature support byte at address 18h = 1
>
>>     and detailed timing descriptor byte 10 = 0x04
>
>> Third:  if EDID bit 0 in feature support byte = 1 &&
>
>>     detailed timing descriptor byte 10 = 0x04
>
>>     then we can check byte 15, if bit 4 in byte 15 = 1 is support RB
>
>>         if EDID bit 0 in feature support byte != 1 ||
>
>>     detailed timing descriptor byte 10 != 0x04,
>
>>     then byte 15 can not be used
>
>>
>
>> The linux code is_rb function not follow the VESA's rule
>
>>
>
>> Signed-off-by: Allen Chen <allen.chen@....com.tw>
>
>> Reported-by: kbuild test robot <lkp@...el.com>
>
>> ---
>
>>  drivers/gpu/drm/drm_edid.c | 36 ++++++++++++++++++++++++++++++------
>
>>  1 file changed, 30 insertions(+), 6 deletions(-)
>
>>
>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>
>> index f5926bf..e11e585 100644
>
>> --- a/drivers/gpu/drm/drm_edid.c
>
>> +++ b/drivers/gpu/drm/drm_edid.c
>
>> @@ -93,6 +93,12 @@ struct detailed_mode_closure {
>
>>    int modes;
>
>>  };
>
>>
>
>> +struct edid_support_rb_closure {
>
>> +   struct edid *edid;
>
>> +   bool valid_support_rb;
>
>> +   bool support_rb;
>
>> +};
>
>> +
>
>>  #define LEVEL_DMT 0
>
>>  #define LEVEL_GTF   1
>
>>  #define LEVEL_GTF2 2
>
>> @@ -2017,23 +2023,41 @@ struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
>
>>    }
>
>>  }
>
>>
>
>> +static bool
>
>> +is_display_descriptor(const u8 *r, u8 tag)
>
>> +{
>
>> +   return (!r[0] && !r[1] && !r[2] && r[3] == tag) ? true : false;
>
>> +}
>
>> +
>
>>  static void
>
>>  is_rb(struct detailed_timing *t, void *data)
>
>>  {
>
>>    u8 *r = (u8 *)t;
>
>> -    if (r[3] == EDID_DETAIL_MONITOR_RANGE)
>
>> -            if (r[15] & 0x10)
>
>> -                    *(bool *)data = true;
>
>> +   struct edid_support_rb_closure *closure = data;
>
>> +   struct edid *edid = closure->edid;
>
>> +
>
>> +   if (is_display_descriptor(r, EDID_DETAIL_MONITOR_RANGE)) {
>
>> +           if (edid->features & BIT(0) && r[10] == BIT(2)) {
>
>> +                   closure->valid_support_rb = true;
>
>> +                   closure->support_rb = (r[15] & 0x10) ? true : false;
>
>> +           }
>
>> +   }
>
>>  }
>
>>
>
>>  /* EDID 1.4 defines this explicitly.  For EDID 1.3, we guess, badly. */
>
>>  static bool
>
>>  drm_monitor_supports_rb(struct edid *edid)
>
>>  {
>
>> +   struct edid_support_rb_closure closure = {
>
>> +           .edid = edid,
>
>> +           .valid_support_rb = false,
>
>> +           .support_rb = false,
>
>> +   };
>
>> +
>
>>    if (edid->revision >= 4) {
>
>> -            bool ret = false;
>
>> -            drm_for_each_detailed_block((u8 *)edid, is_rb, &ret);
>
>> -            return ret;
>
>> +           drm_for_each_detailed_block((u8 *)edid, is_rb, &closure);
>
>> +           if (closure.valid_support_rb)
>
>> +                   return closure.support_rb;
>
>
>
> Are you planning on extending the closure use somehow?
>
>
>
> I did not look up the spec,
>
>
>
> ==> iTE: as the picture below, from VESA E-EDID standard
>
> [cid:image003.jpg@...5A9EA.9B7364D0]
>
>
>
> [cid:image005.jpg@...5A9EA.9B7364D0]
>
>
>
> if EDID bit 0 in feature support byte = 1 && detailed timing descriptor byte 10 = 0x04 then the CVT timing supported.
>
>
>
> [cid:image009.jpg@...5A9EA.9B7364D0]
>
>
>
> If CVT timing supported then we can check byte 15 bit 4 to determine whether the reduced-blanking timings suported or not.
>
> If CVT timing not supported then we can not use byte 15 to judge.
>
> but purely on the code changes alone, you
>
> could just move the edid->features bit check at this level, and not pass
>
> it down, and nothing would change. I.e. don't iterate the EDID at all if
>
> the bit is not set.
>
>
>
> ð  iTE: We still have to check whether detailed timing descriptor byte 10 = 0x04 or not, so it is hard to check at this level
>
> You also don't actually use the distinction between valid_support_rb
>
> vs. support_rb for anything, so the closure just adds code.
>
>
>
> BR,
>
> Jani.
>
>
>
>
>
>>    }
>
>>
>
>>    return ((edid->input & DRM_EDID_INPUT_DIGITAL) != 0);
>
>
>
> --
>
> Jani Nikula, Intel Open Source Graphics Center

-- 
Jani Nikula, Intel Open Source Graphics Center

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ