Call for an EDID parsing library

Call for an EDID parsing library

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 3030 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Call for an EDID parsing library

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 3030 bytes --]

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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Call for an EDID parsing library

[Carsten Haitzler]

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


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster@rasterman.com

Re: Call for an EDID parsing library

[Carsten Haitzler]

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


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster@rasterman.com

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Call for an EDID parsing library

[Hans Verkuil]

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
> 

Re: Call for an EDID parsing library

[Hans Verkuil]

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
> 

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Call for an EDID parsing library

[Jani Nikula]

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.



-- 
Jani Nikula, Intel Open Source Graphics Center

Re: Call for an EDID parsing library

[Jani Nikula]

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.



-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Call for an EDID parsing library

[Simon Ser]

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

Re: Call for an EDID parsing library

[Simon Ser]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Call for an EDID parsing library

[Hans Verkuil]

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

Re: Call for an EDID parsing library

[Hans Verkuil]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Call for an EDID parsing library

[Jonas Ådahl]

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

Re: Call for an EDID parsing library

[Jonas Ådahl]

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 mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Call for an EDID parsing library

[Jani Nikula]

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.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: Call for an EDID parsing library

[Jani Nikula]

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.


-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Call for an EDID parsing library

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Call for an EDID parsing library

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 840 bytes --]

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

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Call for an EDID parsing library

[Jani Nikula]

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.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: Call for an EDID parsing library

[Jani Nikula]

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.


-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Call for an EDID parsing library

[Simon Ser]

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.

Re: Call for an EDID parsing library

[Simon Ser]

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.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Call for an EDID parsing library

[Jani Nikula]

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.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: Call for an EDID parsing library

[Jani Nikula]

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.


-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Call for an EDID parsing library

[Simon Ser]

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.

Re: Call for an EDID parsing library

[Simon Ser]

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.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel