[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1267803981.1316.79.camel@atropine.boston.devel.redhat.com>
Date: Fri, 05 Mar 2010 10:46:21 -0500
From: Adam Jackson <ajax@...hat.com>
To: Jeff Garzik <jeff@...zik.org>
Cc: Matthew Garrett <mjg59@...f.ucam.org>,
Dave Airlie <airlied@...ux.ie>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, dri-devel@...ts.sf.net
Subject: Re: [git pull] drm request 3
On Fri, 2010-03-05 at 06:24 -0500, Jeff Garzik wrote:
> On 03/04/2010 05:59 PM, Adam Jackson wrote:
> > in which you merely remove the nouveau userspace component, and in which
> > I can't tell if you built nouveau into the kernel or not, but I assume
> > you didn't based on your previous post. The X server does only try the
> > one driver before falling back to vesa, which is a bug in the fallback
> > logic I suppose. I've (blindly) fixed that for F13 now.
>
> Thanks. Can this be put into F12 too?
Sure, why not.
> > - you didn't try writing an xorg.conf fragment
> > - you did, and it didn't work anyway
> >
> > The latter case is entirely plausible, as nv is not the sort of driver
> > that gets a lot of love, but I'm not aware of any open bugs about gf9800
> > in particular in nv.
>
> The latter... would modeset in grub interfere, perhaps?
It's not going to do anything if you didn't build a KMS driver. It's
just a kcmdline option like any other; if there's no module to honor it,
then it doesn't do anything. grub doesn't have any particular KMS
awareness.
I'm really going to have to see an X log and dmesg from the failure mode
when actually using nv to diagnose this any further.
- ajax
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists