linux-kernel - Re: [PATCH 04/21] drm/i915: Only use VBT panel mode on eDP if no EDID is found

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: <yun4nzt9akd.fsf@aiko.keithp.com>
Date:	Fri, 30 Sep 2011 10:58:26 -0700
From:	Keith Packard <keithp@...thp.com>
To:	Daniel Vetter <daniel@...ll.ch>
Cc:	Dave Airlie <airlied@...hat.com>, intel-gfx@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 04/21] drm/i915: Only use VBT panel mode on eDP if no EDID is found

On Fri, 30 Sep 2011 18:32:35 +0200, Daniel Vetter <daniel@...ll.ch> wrote:

> Ok, this is way over my head, just checked whether the patch does what it
> claims to - nice exercise in reading dp modeset code ;-)

Yeah, it's purely heuristic -- the VBT contains a mode which was
originally for the LVDS. It's unclear whether it should ever be applied
to an eDP panel, but absent other information, it seems like we should
at least consider it.

Many LVDS panels don't bother to include an EDID rom, or the vendor
didn't bother to hook up the DDC wire; presumably it's cheaper for them
to stick more data in the VBIOS than add hardware.  However, there are
some LVDS panels with EDID roms which contain *incorrect* mode data for
the panel (amazing, I know), and so the driver prefers to use the VBT
data when both are present.

eDP, on the other hand, doesn't require any additional wiring (at least)
to connect up the DDC channel, and eDP panels are required to provide
EDID data. So far, in my (very small) sample set, I've got one machine
which provides accurate VBT *and* EDID data (an HP 2540p) and one
machine which provides inaccurate VBT data but accurate EDID data (a
MacBook air). So, I just decided to prefer the EDID data.

One option would be to extract the current mode from the hardware when
the driver starts and use that if present. But, that might mean that
you'd get different modes depending on whether the machine booted with
the lid closed or open, which seems like a bad plan.

-- 
keith.packard@...el.com

Content of type "application/pgp-signature" skipped