[PATCH v3 2/4] drm/edid: Add a function to check monitor string
Jani Nikula
jani.nikula at linux.intel.com
Tue Mar 5 08:12:46 UTC 2024
On Mon, 04 Mar 2024, Hsin-Yi Wang <hsinyi at chromium.org> wrote:
> On Mon, Mar 4, 2024 at 4:09 PM Jani Nikula <jani.nikula at linux.intel.com> wrote:
>>
>> On Mon, 04 Mar 2024, Hsin-Yi Wang <hsinyi at chromium.org> wrote:
>> > To clarify:
>> > struct drm_edid currently is only internal to drm_edid.c. So with
>> > change we will have to move it to the header drm_edid.h
>>
>> Absolutely not, struct drm_edid must remain an opaque type. The point is
>> that you ask drm_edid.c if there's a match or not, and the panel code
>> does not need to care what's inside struct drm_edid.
>>
>
> Sorry I might be misunderstanding about the requests here:
>
> If drm_edid should remain opaque, then struct drm_edid remains opaque,
> drm_edid_match() should take struct edid *edid as a parameter? just as
> other exposed functions in drm_edid.
No, it should take struct drm_edid *.
> If panel edp doesn't hold drm_edid returned from
> drm_edid_read_base_block(), what should it use to iterate the
> edp_panels array?
Panel edp can hold a *pointer* to struct drm_edid * without knowing the
full type. This is one of the points of struct drm_edid. Focus more of
the EDID parsing within drm_edid.c instead of having everyone parse it
to varying degrees of correctness.
>
> for (panel = edp_panels; panel->panel_id; panel++)
> if(drm_edid_match(drm_edid, panel->ident))
> ...
>
BR,
Jani.
--
Jani Nikula, Intel
More information about the dri-devel
mailing list