All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarod Wilson <jarod@redhat.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: dri-devel@lists.sourceforge.net, xorg-devel@lists.x.org,
	linux-kernel@vger.kernel.org, notting@redhat.com,
	Zhenyu Wang <zhenyu.z.wang@intel.com>,
	Fu Michael <michael_fu@linux.intel.com>
Subject: Re: [PATCH] drm: ignore LVDS on intel graphics systems that lie about having it
Date: Mon, 6 Apr 2009 13:29:53 -0400	[thread overview]
Message-ID: <200904061329.53824.jarod@redhat.com> (raw)
In-Reply-To: <20090406095216.4361d128@hobbes>

On Monday 06 April 2009 12:52:16 Jesse Barnes wrote:
> On Mon, 6 Apr 2009 10:11:25 -0400
> Jarod Wilson <jarod@redhat.com> wrote:
> 
> > There are a number of small form factor desktop systems with Intel
> > mobile graphics chips that lie and say they have an LVDS. With kernel
> > mode-setting, this becomes a problem, and makes native resolution
> > boot go haywire -- for example, my Dell Studio Hybrid, hooked to a
> > 1920x1080 display claims to have a 1024x768 LVDS, and the resulting
> > graphical boot on the 1920x1080 display uses only the top left
> > 1024x768, and auto-configured X will end up only 1024x768 as well.
> > With this change, graphical boot and X both do 1920x1080 as expected.
> > 
> > Note that we're simply embracing and extending the early bail-out code
> > in place for the Mac Mini here. The xorg intel driver uses pci
> > subsystem device and vendor id for matching, while we're using dmi
> > lookups here. The MSI addition is courtesy of and tested by Bill
> > Nottingham.
> > 
> > One minor issue... Current Fedora rawhide, video playback using Xv
> > makes X go off into the weeds with this patch added, but that's a bug
> > elsewhere, still confident this patch DTRT.
> > 
> > Signed-off-by: Jarod Wilson <jarod@redhat.com>
> > Tested-by: Bill Nottingham <notting@redhat.com>
> 
> The 2D driver has a similar set of quirks, but since we started that
> list we've found that the VBIOS should contain a pretty reliable table
> indicating which outputs are available, including LVDS.  I think if we
> can figure out how to parse it reliably (accounting for VBIOS
> versioning and structure size changes) we shouldn't need this patch.
> If we can't get that done in time for 2.6.30 though I'm all for
> including this.

Sounds like a plan to me. Either way, would this patch still make sense
for submission to the 2.6.29.x stable series? I've already tacked it
onto the Fedora 2.6.29 kernel builds, fwiw.

-- 
Jarod Wilson
jarod@redhat.com

  reply	other threads:[~2009-04-06 17:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-06 14:11 [PATCH] drm: ignore LVDS on intel graphics systems that lie about having it Jarod Wilson
2009-04-06 16:52 ` Jesse Barnes
2009-04-06 17:29   ` Jarod Wilson [this message]
2009-04-06 17:39     ` Jesse Barnes
2009-05-04 22:14       ` Jesse Barnes
2009-04-07  0:50   ` Wang, Zhenyu Z
2009-04-15  1:41     ` Jarod Wilson

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=200904061329.53824.jarod@redhat.com \
    --to=jarod@redhat.com \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael_fu@linux.intel.com \
    --cc=notting@redhat.com \
    --cc=xorg-devel@lists.x.org \
    --cc=zhenyu.z.wang@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 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.