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?). It does not necessarily need to be a new project. Would edid-decode project be open to adding a C library ABI? edid-decode is already MIT licensed and seems to have a lot of code, too, but that's all I know for now. Would there be anyone interested to take lead or work on a project like this? 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 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. What do you think? Could anyone spare their time for this? Who would be interested in using it if this library appeared? Thanks, pq
Attachment:
pgpRIN6rfREV8.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
