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. -Doug