From: Jani Nikula <jani.nikula@intel.com>
To: Simon Ser <contact@emersion.fr>
Cc: cooper.chiou@intel.com, william.tseng@intel.com,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Daniel Stone <daniel@fooishbar.org>
Subject: Re: [Intel-gfx] [v8 3/5] drm/edid: read HF-EEODB ext block
Date: Wed, 23 Mar 2022 14:14:29 +0200 [thread overview]
Message-ID: <87o81wj26y.fsf@intel.com> (raw)
In-Reply-To: <v5n3uG2NAQA-QZycdMslyq4R7fW8xPTlrIsDkPubuVyx5tf_VG_YZp_GHylatC_-fTg01rR8sZtbHcGSzqdho8YZyuKDihIX-jJ4CGAgems=@emersion.fr>
On Wed, 23 Mar 2022, Simon Ser <contact@emersion.fr> wrote:
> On Wednesday, March 23rd, 2022 at 13:02, Jani Nikula <jani.nikula@intel.com> wrote:
>
>> Simon and Daniel also tell me on IRC we can't just modify the base block
>> extension count to match HF-EEODB to dodge the problem, because the EDID
>> gets exposed to userspace.
>
> I'm not familiar how the EDID blob gets exposed to user-space. If the
> EDID data gets copied when creating the blob, and the blob is created
> before the kernel mutates the EDID to accomodate for HF-EEODB, then
> this proposal might still be workable.
You'd still end up with tracking separate copies of the EDID, which is
not necessarily easier. There are almost 70 calls to update the
connector EDID property that gets exposed to userspace, and the call
sites would need to know which copy to pass.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2022-03-23 12:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-17 12:41 [Intel-gfx] [v8 0/5] enhanced edid driver compatibility Lee Shawn C
2022-03-17 12:41 ` [Intel-gfx] [v8 1/5] drm/edid: seek for available CEA block from specific EDID block index Lee Shawn C
2022-03-17 12:41 ` [Intel-gfx] [v8 2/5] drm/edid: parse multiple CEA extension block Lee Shawn C
2022-03-17 12:42 ` [Intel-gfx] [v8 3/5] drm/edid: read HF-EEODB ext block Lee Shawn C
2022-03-23 10:11 ` Jani Nikula
2022-03-23 12:02 ` Jani Nikula
2022-03-23 12:04 ` Simon Ser
2022-03-23 12:14 ` Jani Nikula [this message]
2022-03-23 14:26 ` Ville Syrjälä
2022-03-17 12:42 ` [Intel-gfx] [v8 4/5] drm/edid: parse HF-EEODB CEA extension block Lee Shawn C
2022-03-17 12:42 ` [Intel-gfx] [v8 5/5] drm/edid: check for HF-SCDB block Lee Shawn C
2022-03-17 12:53 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for enhanced edid driver compatibility (rev4) Patchwork
2022-03-17 12:55 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-03-17 13:28 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-17 15:05 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
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=87o81wj26y.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=contact@emersion.fr \
--cc=cooper.chiou@intel.com \
--cc=daniel@fooishbar.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=william.tseng@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox