Hi Pekka, On 07/04/2021 10:44, Pekka Paalanen wrote: > Hi all, > > with display servers proliferating thanks to Wayland, and the Linux > kernel exposing only a very limited set of information based on EDID > (rightfully so!), the need to interpret EDID blobs is spreading even > more. I would like to start the discussion about starting a project to > develop a shared library for parsing EDID blobs. This is not the first > time either, other people have suggested it years and years ago already, > but apparently it didn't quite materialise as far as I know. > > Right now, it seems that more or less every display server and other > KMS application is hand-rolling its own EDID parsing code, even for the > most trivial information (monitor make, model, and serial number). With > HDR and color management support coming to Wayland, the need to parse > more things out of EDID will only increase. These things are not > exposed by the kernel, and most of these things have no use for the > kernel either. > > My personal motivation for this is that I don't want to be developing > or reviewing yet another partial EDID parser implementation in Weston. > > I recall ponderings about sharing the same EDID parsing code between > the kernel and userspace, but I got the feeling that it would be a > hindrance in process more than a benefit from sharing code. It would > need to live in the kernel tree, to be managed with the kernel > development process, use the kernel "standard libraries", and adhere to > kernel programming style - all which are good and fine, but maybe also > more restricting than useful in this case. Therefore I would suggest a > userspace-only library. > > Everyone hand-rolling their own parsing code has the obvious > disadvantages. In the opposite, I would expect a new shared EDID > parsing library and project to: > - be hosted under gitlab.freedesktop.org > - be MIT licensed > - offer at least a C ABI > - employ mandatory Gitlab CI to ensure with sample EDID blobs that it > cannot regress > > Prior art can be found in various places. I believe Xorg xserver has > its battle-tested EDID parsing code. Ajax once played with the idea in > https://cgit.freedesktop.org/~ajax/libminitru/ . Then we have > https://git.linuxtv.org/edid-decode.git too which has code and test > data but not a C ABI (right?). Correct, I moved it to C++. It was never designed to be a library, it was primarily meant to turn an EDID into a human readable format. And these days it is also a very powerful tool to verify EDIDs. It is the most complete EDID parser I know based on the various standards. > It does not necessarily need to be a new project. Would edid-decode > project be open to adding a C library ABI? I would be open to that. The best way would be to create a C library that turns the EDID blocks into C structures, while edid-decode itself remains C++ and uses the C library to do the parsing. While edid-decode supports a large range of Extension Blocks, a C library could probably limit itself to the base block, CTA-861 blocks and DisplayID blocks. > > edid-decode is already MIT licensed and seems to have a lot of code, > too, but that's all I know for now. It is as far as I know the most complete parser. > > Would there be anyone interested to take lead or work on a project like > this? I can assist/advice and do code reviews, but I don't have the time myself to do the actual work. > > Personally I don't think I'd be working on it, but I would be really > happy to use it in Weston. > > Should it be a new project, or grow inside edid-decode or something > else? I think it would make sense if it is grown as a library used by edid-decode. The edid-decode utility is under active maintenance and follows the latest EDID standards, so that will probably help the quality of the library. My main requirement would be that the edid-decode functionality is not affected, especially the conformity checks are still performed. And that support for new/updated EDID standards can easily be implemented, but that's exactly what you would want in an edid library. > > I believe MIT license is important to have wide adoption of it. C ABI > similarly. Also that it would be a "small" library without heavy > dependencies. It shouldn't need any dependencies. edid-decode doesn't need any either except for -lm, which is probably not needed for the library part. > What do you think? Could anyone spare their time for this? Didn't you just volunteer? :-) :-) Regards, Hans > > Who would be interested in using it if this library appeared? > > > Thanks, > pq > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
