On Tue, 8 Mar 2022 13:09:37 +0100 Hans Verkuil <hverkuil-cisco@xxxxxxxxx> wrote: > Hi Shashank, > > There is no cover letter for this series, so I'll just reply to the > first patch, but my comments are high-level and not specific to this > patch. > > To be honest, I am not at all convinced that using edid-decode as a > parser library is the right thing to do. It was never written with that > in mind. The two purposes of edid-decode are to: > > 1) Convert the EDID to a human readable text, and > 2) Verify if the EDID conforms to the various standards and is internally > consistent. > > As a result the state information that edid-decode stores is just the > state that it needs to check conformity across Extension Blocks and/or > Data Blocks. Most of the parsed data is just printed to stdout and checked > and then forgotten. > > I have considered if it would make sense to make a library to parse and > store the EDID data and have edid-decode sit on top of that, but that will > make the conformity tests much harder. It's kind of interwoven with the > parsing and a parser library is really not interested in that anyway. > > I think edid-decode can function very well as a reference source for > a real EDID parser since edid-decode is very complete, but not as a > EDID parser library. > Hi all, since this discussion, more people have joined the effort and the consensus became to start a new project instead of pushing to edid-decode upstream. The new project is at https://gitlab.freedesktop.org/emersion/libdisplay-info where we are currently discussing what the API should look like in the issues and merge request comments, so there is essentially no code yet. If the project gains enough traction, I expect it will be moved into a non-personal namespace under fd.o to live a life of its own. Thanks, pq
Attachment:
pgpaswb3ei5Rc.pgp
Description: OpenPGP digital signature
