Call for an EDID parsing library
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 pgpXbKvZxt5aJ.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Call for an EDID parsing library
On Wed, 7 Apr 2021 11:44:04 +0300 Pekka Paalanen said: > 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. I'd say it needs nothing more than libc - I can't see the justification for more than that. If this is the case along with the above you have given, then I see no reason for it to not be used by everyone other than the usual user complaint of "too many dependencies (of a compositor)". :) I'd definitely consider using it. > What do you think? Could anyone spare their time for this? > > Who would be interested in using it if this library appeared? > > > Thanks, > pq -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Call for an EDID parsing library
On Wed, 07 Apr 2021, Hans Verkuil wrote: > It is the most complete EDID parser I know based on the various standards. Does it support pure DisplayID in addition to DisplayID blocks embedded to EDID extension blocks? I think we'll be needing that sometime in the near future. (We don't yet support that in the kernel either.) BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Call for an EDID parsing library
FWIW, with my Sway/wlroots hat on I think this is a great idea and I'd definitely be interested in using such as library. A C API with no dependencies is pretty important from my point-of-view. I'd prefer if C++ was not used at all (and could almost be baited into doing the work if that were the case), but it seems that ship has sailed already. Simon ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Call for an EDID parsing library
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 > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Call for an EDID parsing library
On 07/04/2021 12:31, Jani Nikula wrote: > On Wed, 07 Apr 2021, Hans Verkuil wrote: >> It is the most complete EDID parser I know based on the various standards. > > Does it support pure DisplayID in addition to DisplayID blocks embedded > to EDID extension blocks? I think we'll be needing that sometime in the > near future. (We don't yet support that in the kernel either.) It doesn't, but that shouldn't be too hard to implement. Do you have examples of that? If I had some, then I could implement support for it in edid-decode. Regards, Hans ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Call for an EDID parsing library
On Wed, Apr 07, 2021 at 10:59:18AM +, Simon Ser wrote: > FWIW, with my Sway/wlroots hat on I think this is a great idea and I'd > definitely be interested in using such as library. A C API with no > dependencies is pretty important from my point-of-view. > > I'd prefer if C++ was not used at all (and could almost be baited into > doing the work if that were the case), but it seems that ship has > sailed already. The same for Mutter / GNOME, not having to maintain a EDID parser would be great. Though personally I don't care if it's implemented in C++, C or whatever, as long as there is a C API to use. Jonas > > Simon > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Call for an EDID parsing library
On 07/04/2021 13:40, Jonas Ådahl wrote: On Wed, Apr 07, 2021 at 10:59:18AM +, Simon Ser wrote: FWIW, with my Sway/wlroots hat on I think this is a great idea and I'd definitely be interested in using such as library. A C API with no dependencies is pretty important from my point-of-view. I'd prefer if C++ was not used at all (and could almost be baited into doing the work if that were the case), but it seems that ship has sailed already. The same for Mutter / GNOME, not having to maintain a EDID parser would be great. Though personally I don't care if it's implemented in C++, C or whatever, as long as there is a C API to use. Mir too - although a C++ API would be also fine for us. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libxkbcommon 1.2.1
libxkbcommon 1.2.1 = - Fix `xkb_x11_keymap_new_from_device()` failing when the keymap contains key types with missing level names, like the one used by the `numpad:mac` option in xkeyboard-config. Regressed in 1.2.0. Tarball: git tag: xkbcommon-1.2.1 https://xkbcommon.org/download/libxkbcommon-1.2.1.tar.xz SHA256: e833a7d3024c9bb9d5eb2b20f6d5de08865541f21bb7ba227c83cbd236691fb3 libxkbcommon-1.2.1.tar.xz Ran ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
