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
On Wed, 7 Apr 2021 11:44:04 +0300 Pekka Paalanen ppaalanen@gmail.com 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
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
On Wed, 07 Apr 2021, Hans Verkuil hverkuil@xs4all.nl 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.
On 07/04/2021 12:31, Jani Nikula wrote:
On Wed, 07 Apr 2021, Hans Verkuil hverkuil@xs4all.nl 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
On Wed, 07 Apr 2021, Hans Verkuil hverkuil@xs4all.nl wrote:
On 07/04/2021 12:31, Jani Nikula wrote:
On Wed, 07 Apr 2021, Hans Verkuil hverkuil@xs4all.nl 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.
Alas, I don't. We don't come across them naturally, because the kernel does not follow VESA E-DDC 1.3 to read 0x52 address to read the plain DisplayID. I guess it's also common to add DisplayID 2.0 data blocks in EDID extensions (and I see that edid-decode handles them), though this is not described in DisplayID 2.0 spec the way it is in older DisplayID specs.
The differences aren't that big, really. Slightly different constraints on the block size when they're not embedded in EDID, as well as different mandatory blocks.
Anyway, this is only tangentially related to the library. I just think we need to take DisplayID better into account also in the *users* of the library, as they shouldn't really even look at the EDID if the plain DisplayID is there, per E-DDC 1.3 section 3.1.
BR, Jani.
On Thu, 08 Apr 2021 16:49:37 +0300 Jani Nikula jani.nikula@linux.intel.com wrote:
Anyway, this is only tangentially related to the library. I just think we need to take DisplayID better into account also in the *users* of the library, as they shouldn't really even look at the EDID if the plain DisplayID is there, per E-DDC 1.3 section 3.1.
That makes me wonder what the kernel DRM uAPI for getting a DisplayID block into userspace would be. A new read-only KMS connector property?
Which means userspace (e.g. Weston) needs to know to read the new property. If it does that, then it already knows that it should favour DisplayID over EDID, and there is little the library could do to help with that.
Unless you think the library should be making DRM ioctls, which doesn't sound good to me.
Thanks, pq
On Thu, 08 Apr 2021, Pekka Paalanen ppaalanen@gmail.com wrote:
On Thu, 08 Apr 2021 16:49:37 +0300 Jani Nikula jani.nikula@linux.intel.com wrote:
Anyway, this is only tangentially related to the library. I just think we need to take DisplayID better into account also in the *users* of the library, as they shouldn't really even look at the EDID if the plain DisplayID is there, per E-DDC 1.3 section 3.1.
That makes me wonder what the kernel DRM uAPI for getting a DisplayID block into userspace would be. A new read-only KMS connector property?
It's certainly a model everyone's used to working with. Is it worth coming up with something new when you anyway have to deal with the existing edid property for years to come?
Which means userspace (e.g. Weston) needs to know to read the new property. If it does that, then it already knows that it should favour DisplayID over EDID, and there is little the library could do to help with that.
Agreed.
One of the problems for this uABI is that technically you're not supposed to read the EDID if the DisplayID is available. But the kernel needs to read both to expose both to userspace. I don't really see a way around that.
The spec allows for leaving out EDID at 0x50 completely, which may eventually require updating kernel and userspace to be DisplayID aware.
Unless you think the library should be making DRM ioctls, which doesn't sound good to me.
Agreed, keep it simple.
I'd say the library should probably stick to parsing an in-memory blob or fd passed to it, and focus on providing parsed information that's independent of the underlying data structure, whether it's DisplayID or EDID. Perhaps that should be the takeaway; try to minimize parsed data where the consumer needs to know whether it originated from DisplayID or EDID?
BR, Jani.
On Thursday, April 8th, 2021 at 4:58 PM, Jani Nikula jani.nikula@linux.intel.com wrote:
Perhaps that should be the takeaway; try to minimize parsed data where the consumer needs to know whether it originated from DisplayID or EDID?
So an EDID/DisplayID abstraction layer?
It sounds like only an EDID and DisplayID expert could come up with a sane API for that. Also some metadata will only be available in one format and not the other.
On Thu, 08 Apr 2021, Simon Ser contact@emersion.fr wrote:
On Thursday, April 8th, 2021 at 4:58 PM, Jani Nikula jani.nikula@linux.intel.com wrote:
Perhaps that should be the takeaway; try to minimize parsed data where the consumer needs to know whether it originated from DisplayID or EDID?
So an EDID/DisplayID abstraction layer?
It sounds like only an EDID and DisplayID expert could come up with a sane API for that. Also some metadata will only be available in one format and not the other.
Well, some of the data *already* comes from DisplayID extensions in the EDID.
My point is, if you parse displayid and edid into different structures and APIs, what will the code bases using the library end up looking like? Not pretty? Implementing the same conditionals all over the place?
Anyway. I feel like I'm derailing this a bit, and I really don't want that to happen. I think DisplayID is a consideration that should not be forgotten, but it's probably not the first priority here.
BR, Jani.
On Thursday, April 8th, 2021 at 5:28 PM, Jani Nikula jani.nikula@linux.intel.com wrote:
On Thu, 08 Apr 2021, Simon Ser contact@emersion.fr wrote:
On Thursday, April 8th, 2021 at 4:58 PM, Jani Nikula jani.nikula@linux.intel.com wrote:
Perhaps that should be the takeaway; try to minimize parsed data where the consumer needs to know whether it originated from DisplayID or EDID?
So an EDID/DisplayID abstraction layer?
It sounds like only an EDID and DisplayID expert could come up with a sane API for that. Also some metadata will only be available in one format and not the other.
Well, some of the data already comes from DisplayID extensions in the EDID.
My point is, if you parse displayid and edid into different structures and APIs, what will the code bases using the library end up looking like? Not pretty? Implementing the same conditionals all over the place? Anyway. I feel like I'm derailing this a bit, and I really don't want that to happen. I think DisplayID is a consideration that should not be forgotten, but it's probably not the first priority here.
I agree with the goal. I'm just saying that it considerably increases the complexity of the task.
If you're just doing an EDID library, you can just expose the EDID specific bits with a sane API. If you're designing an abstraction layer, you need to have a good look at both APIs, try to come up with common data structures that fit both, and be aware of the upcoming spec changes to not be stuck with a bad API.
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
On Wed, Apr 07, 2021 at 10:59:18AM +0000, 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
dri-devel@lists.freedesktop.org
-
Carsten Haitzler -
Hans Verkuil -
Jani Nikula -
Jonas Ådahl -
Pekka Paalanen -
Simon Ser