Call for an EDID parsing library

[Pekka Paalanen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20210407/177e2642/attachment.sig>