linux-kernel - Re: [PATCH 3/3] drm/panel-edp: Choose correct preferred mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ze5xz52jt4helttcmntzmr6fr4ohu7wtslywalbxc4w7w6uvly@nwweqyyl4wf2>
Date:   Mon, 6 Nov 2023 09:06:41 +0100
From:   Maxime Ripard <mripard@...nel.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Hsin-Yi Wang <hsinyi@...omium.org>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Jessica Zhang <quic_jesszhan@...cinc.com>,
        Sam Ravnborg <sam@...nborg.org>
Subject: Re: [PATCH 3/3] drm/panel-edp: Choose correct preferred mode

On Thu, Nov 02, 2023 at 07:33:48AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Wed, Nov 1, 2023 at 11:31 PM Dmitry Baryshkov
> <dmitry.baryshkov@...aro.org> wrote:
> >
> > On Wed, 1 Nov 2023 at 23:26, Hsin-Yi Wang <hsinyi@...omium.org> wrote:
> > >
> > > If a non generic edp-panel is under aux-bus, the mode read from edid would
> > > still be selected as preferred and results in multiple preferred modes,
> > > which is ambiguous.
> > >
> > > If a hard-coded mode is present, unset the preferred bit of the modes read
> > > from edid.
> >
> > Can we skip the EDID completely if the hardcoded override is present?
> 
> Yeah, I wondered about that too. The blending of the hardcoded with
> the EDID predates my involvement with the driver. You can see even as
> of commit 280921de7241 ("drm/panel: Add simple panel support") that
> the driver would start with the EDID modes (if it had them) and then
> go onto add the hardcoded modes. At least for eDP panels, though,
> nobody (or almost nobody?) actually provided panel-simple a DDC bus at
> the same time it was given a hardcoded panel.
> 
> I guess I could go either way, but I have a slight bias to adding the
> extra modes and just making it clear to userspace that none of them
> are "preferred". That seems like it would give userspace the most
> flexibility

I disagree. "Flexibility" here just means "the way to shoot itself in
the foot without knowing it's aiming at its foot".

If a mode is broken, we shouldn't expose it, just like we don't for all
modes that require a maximum frequency higher than what the controller
can provide on HDMI for example.

> and also is closer to what we've historically done (though,
> historically, we just allowed there to be more than one "preferred"
> mode).

I have no idea what history you're referring to here

> One thing we definitely want to do, though, is to still expose the
> EDID to userspace even if we're using a hardcoded mode. I believe
> that, at least on ChromeOS, there are some tools that look at the EDID
> directly for some reason or another.

If the EDID is known to be broken and unreliable, what's the point?

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)