[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <5b55a1$ijk39t@fmsmga002.fm.intel.com>
Date: Mon, 08 Nov 2010 12:13:17 +0000
From: Chris Wilson <chris@...is-wilson.co.uk>
To: Jon Masters <jonathan@...masters.org>
Cc: intel-gfx <intel-gfx@...ts.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Intel-gfx] [bisected] offset display bug in i915
On Mon, 08 Nov 2010 06:29:09 -0500, Jon Masters <jonathan@...masters.org> wrote:
> On Mon, 2010-11-08 at 06:22 -0500, Jon Masters wrote:
> > As I mentioned on IRC, I'm familiar with how I2C works electrically, and
> > therefore EDID implementation as a concept, but I am not really a
> > graphics hacker so I wasn't aware that you prefer edid-decode :)
> >
> > Here is a decoded version of the output:
>
> And here is an old file I had with the output when running a broken
> kernel with the cacheing enabled:
They look to be identical. So it is not necessarily the caching that is
the issue, but that we now no longer do an essential step whilst bringing
up the lvds. Can you just check that the reported EDIDs are the same for
when it is behaving correctly and when the display is offset?
The secondary change in the commit was to use drm_get_edid() directly
during device detection which delayed setting the EDID property on the
connection until get_modes(). Does this make a difference?
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds
index f1a6499..17bcb7d 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -940,7 +940,10 @@ void intel_lvds_init(struct drm_device *dev)
intel_lvds->edid = drm_get_edid(connector,
&dev_priv->gmbus[pin].adapter);
- if (!intel_lvds->edid) {
+ if (intel_lvds->edid) {
+ drm_mode_connector_update_edid_property(connector,
+ intel_lvds->edid);
+ } else {
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists