[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJMQK-gKF+ZeAe4Hp8di83Zx8gp-BJ0vuj6uzi0hsaxeju8GyQ@mail.gmail.com>
Date: Mon, 4 Mar 2024 11:55:23 -0800
From: Hsin-Yi Wang <hsinyi@...omium.org>
To: Doug Anderson <dianders@...omium.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>, Jani Nikula <jani.nikula@...ux.intel.com>,
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 1/2] drm_edid: Add a function to get EDID base block
On Mon, Mar 4, 2024 at 8:17 AM Doug Anderson <dianders@...omium.org> wrote:
>
> Hi,
>
> On Sun, Mar 3, 2024 at 1:30 PM Dmitry Baryshkov
> <dmitry.baryshkov@...aro.org> wrote:
> >
> > > The problem is that Dmitry didn't like the idea of using a hash and in
> > > v2 Hsin-Yi has moved to using the name of the display. ...except of
> > > course that eDP panels don't always properly specify
> > > "EDID_DETAIL_MONITOR_NAME". See the discussion [1]. If you want to see
> > > some of the EDIDs involved, you can see Hsin-Yi's post [2]. The panels
> > > included stuff like this:
> > >
> > > Alphanumeric Data String: 'AUO'
> > > Alphanumeric Data String: 'B116XAN04.0 '
> > >
> > > The fact that there is more than one string in there makes it hard to
> > > just "return" the display name in a generic way. The way Hsin-Yi's
> > > code was doing it was that it would consider it a match if the panel
> > > name was in any of the strings...
> > >
> > > How about this as a solution: we change drm_edid_get_panel_id() to
> > > return an opaque type (struct drm_edid_panel_id_blob) that's really
> > > just the first block of the EDID but we can all pretend that it isn't.
> > > Then we can add a function in drm_edid.c that takes this opaque blob,
> > > a 32-bit integer (as per drm_edid_encode_panel_id()), and a string
> > > name and it can tell us if the blob matches?
> >
> > Would it be easier to push drm_edid_match to drm_edid.c? It looks way
> > more simpler than the opaque blob.
>
> Yeah, that sounds reasonable / cleaner to me. Good idea! Maybe Hsin-Yi
> will be able to try this out and see if there's a reason it wouldn't
> work.
Thanks for all the suggestions. I sent out v3, which still has a blob
type since we need
1. get panel id
2. do the string matching.
And I felt that packing these 2 steps into one function may make that
function do multiple tasks?
But let me know if it's preferred in this way.
v3: https://lore.kernel.org/lkml/20240304195214.14563-1-hsinyi@chromium.org/
>
> -Doug
Powered by blists - more mailing lists