All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
	linux-media@vger.kernel.org, xorg-devel@lists.x.org,
	dri-devel@lists.freedesktop.org,
	wayland-devel@lists.freedesktop.org
Subject: Re: Call for an EDID parsing library
Date: Thu, 8 Apr 2021 17:13:11 +0300	[thread overview]
Message-ID: <20210408171311.61f433bd@eldfell> (raw)
In-Reply-To: <87r1jkj37y.fsf@intel.com>


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

WARNING: multiple messages have this Message-ID (diff)
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
	dri-devel@lists.freedesktop.org,
	wayland-devel@lists.freedesktop.org, xorg-devel@lists.x.org,
	linux-media@vger.kernel.org
Subject: Re: Call for an EDID parsing library
Date: Thu, 8 Apr 2021 17:13:11 +0300	[thread overview]
Message-ID: <20210408171311.61f433bd@eldfell> (raw)
In-Reply-To: <87r1jkj37y.fsf@intel.com>

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

  reply	other threads:[~2021-04-08 14:13 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-07  8:44 Call for an EDID parsing library Pekka Paalanen
2021-04-07  8:44 ` 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 [this message]
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=20210408171311.61f433bd@eldfell \
    --to=ppaalanen@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hverkuil@xs4all.nl \
    --cc=jani.nikula@linux.intel.com \
    --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.