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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 07 Mar 2024 22:27:55 +0200
From: Jani Nikula <jani.nikula@...ux.intel.com>
To: Hsin-Yi Wang <hsinyi@...omium.org>
Cc: Doug Anderson <dianders@...omium.org>, Dmitry Baryshkov
 <dmitry.baryshkov@...aro.org>, Neil Armstrong <neil.armstrong@...aro.org>,
 Jessica Zhang <quic_jesszhan@...cinc.com>, Sam Ravnborg
 <sam@...nborg.org>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann
 <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Daniel Vetter
 <daniel@...ll.ch>, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 6/6] drm/panel-edp: Fix AUO 0x405c panel naming and
 add a variant

On Thu, 07 Mar 2024, Hsin-Yi Wang <hsinyi@...omium.org> wrote:
> On Thu, Mar 7, 2024 at 5:28 AM Jani Nikula <jani.nikula@...ux.intel.com> wrote:
>>
>> On Wed, 06 Mar 2024, Doug Anderson <dianders@...omium.org> wrote:
>> > Hi,
>> >
>> > On Wed, Mar 6, 2024 at 12:04 PM Hsin-Yi Wang <hsinyi@...omium.org> wrote:
>> >>
>> >> @@ -1009,6 +1009,19 @@ static const struct panel_desc auo_b101ean01 = {
>> >>         },
>> >>  };
>> >>
>> >> +static const struct drm_display_mode auo_b116xa3_mode = {
>> >> +       .clock = 70589,
>> >> +       .hdisplay = 1366,
>> >> +       .hsync_start = 1366 + 40,
>> >> +       .hsync_end = 1366 + 40 + 40,
>> >> +       .htotal = 1366 + 40 + 40 + 32,
>> >> +       .vdisplay = 768,
>> >> +       .vsync_start = 768 + 10,
>> >> +       .vsync_end = 768 + 10 + 12,
>> >> +       .vtotal = 768 + 10 + 12 + 6,
>> >> +       .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
>> >> +};
>> >> +
>> >>  static const struct drm_display_mode auo_b116xak01_mode = {
>> >>         .clock = 69300,
>> >>         .hdisplay = 1366,
>> >> @@ -1990,7 +2003,9 @@ static const struct edp_panel_entry edp_panels[] = {
>> >>         EDP_PANEL_ENTRY('A', 'U', 'O', 0x239b, &delay_200_500_e50, "B116XAN06.1"),
>> >>         EDP_PANEL_ENTRY('A', 'U', 'O', 0x255c, &delay_200_500_e50, "B116XTN02.5"),
>> >>         EDP_PANEL_ENTRY('A', 'U', 'O', 0x403d, &delay_200_500_e50, "B140HAN04.0"),
>> >> -       EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, &auo_b116xak01.delay, "B116XAK01.0"),
>> >> +       EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, &auo_b116xak01.delay, "B116XAN04.0"),
>> >> +       EDP_PANEL_ENTRY2('A', 'U', 'O', 0x405c, &auo_b116xak01.delay, "B116XAK01.0 ",
>> >
>> > Remove the trailing space from the string above now?
>>
>> Maybe it actually needs to be considered part of the name; see my other
>> reply in the earlier patch.
>>
> I randomly checked 3 of the AUO panels that I had a datasheet with,
> and all of them have a white space padding before \n.
> The descriptor of that field is marked as "Reserved for definition",
> unlike other characters, representing the name, which are marked with
> "Manufacture P/N".
>
> For this example, do we still want to consider the white space part of
> the name? I know they didn't follow the spec exactly.

If there's one thing that's for sure, EDIDs are full of stuff like this,
across the board.

Ignoring the whitespace at the end seemed reasonable, initially, to me
too. But the question is, if we start catering for this, what else
should we cater for? Do we keep adding "reasonable" interpretations, or
just go by the spec?


BR,
Jani.


>
>> >
>> > Aside from that:
>> >
>> > Reviewed-by: Douglas Anderson <dianders@...omium.org>
>>
>> --
>> Jani Nikula, Intel

-- 
Jani Nikula, Intel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ