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