All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <ppaalanen@gmail.com>
To: dri-devel@lists.freedesktop.org,
	wayland-devel@lists.freedesktop.org, xorg-devel@lists.x.org,
	linux-media@vger.kernel.org
Subject: Call for an EDID parsing library
Date: Wed, 7 Apr 2021 11:44:04 +0300	[thread overview]
Message-ID: <20210407114404.13b41822@eldfell> (raw)


[-- 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

WARNING: multiple messages have this Message-ID (diff)
From: Pekka Paalanen <ppaalanen@gmail.com>
To: dri-devel@lists.freedesktop.org,
	wayland-devel@lists.freedesktop.org, xorg-devel@lists.x.org,
	linux-media@vger.kernel.org
Subject: Call for an EDID parsing library
Date: Wed, 7 Apr 2021 11:44:04 +0300	[thread overview]
Message-ID: <20210407114404.13b41822@eldfell> (raw)

[-- 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 --]

             reply	other threads:[~2021-04-07  8:44 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-07  8:44 Pekka Paalanen [this message]
2021-04-07  8:44 ` Call for an EDID parsing library Pekka Paalanen
2021-04-07  8:55 ` Carsten Haitzler
2021-04-07  8:55   ` Carsten Haitzler
2021-04-07  9:34 ` Hans Verkuil
2021-04-07  9:34   ` Hans Verkuil
2021-04-07 10:31   ` Jani Nikula
2021-04-07 10:31     ` Jani Nikula
2021-04-07 11:00     ` Hans Verkuil
2021-04-07 11:00       ` Hans Verkuil
2021-04-08 13:49       ` Jani Nikula
2021-04-08 13:49         ` Jani Nikula
2021-04-08 14:13         ` Pekka Paalanen
2021-04-08 14:13           ` Pekka Paalanen
2021-04-08 14:58           ` Jani Nikula
2021-04-08 14:58             ` Jani Nikula
2021-04-08 15:10             ` Simon Ser
2021-04-08 15:10               ` Simon Ser
2021-04-08 15:28               ` Jani Nikula
2021-04-08 15:28                 ` Jani Nikula
2021-04-08 15:34                 ` Simon Ser
2021-04-08 15:34                   ` Simon Ser
2021-04-07 10:59 ` Simon Ser
2021-04-07 10:59   ` Simon Ser
2021-04-07 12:40   ` Jonas Ådahl
2021-04-07 12:40     ` Jonas Ådahl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210407114404.13b41822@eldfell \
    --to=ppaalanen@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-media@vger.kernel.org \
    --cc=wayland-devel@lists.freedesktop.org \
    --cc=xorg-devel@lists.x.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.