On Mon, 04 Mar 2024, Hsin-Yi Wang <hsinyi@xxxxxxxxxxxx> wrote: > On Mon, Mar 4, 2024 at 8:17 AM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: >> >> Hi, >> >> On Sun, Mar 3, 2024 at 1:30 PM Dmitry Baryshkov >> <dmitry.baryshkov@xxxxxxxxxx> 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@xxxxxxxxxxxx/ I still don't like it, but incorporating all the ideas here, and in the previous patches, I think I have a suggestion that covers all cases in a reasonable manner [1]. Sorry about being so inflexible about this. I've just put 140+ commits worth of effort in drm_edid.c in the past couple of years, and I'm keen on keeping it nice and tidy. :) BR, Jani. [1] https://lore.kernel.org/r/87a5nd4tsg.fsf@xxxxxxxxx > >> >> -Doug -- Jani Nikula, Intel
