[PATCH] Move the logic for matching devices out of probe routine.

[Aaron Plattner]

On Mon, Sep 14, 2009 at 12:49:45PM -0700, Mario Limonciello wrote:
> Hi Aaron:
> 
> Aaron Plattner wrote:
> > On Mon, Sep 14, 2009 at 09:03:41AM -0700, Mario Limonciello wrote:
> >   
> > I'd like to leave the driver as-is and instead work on improving the
> > server's driver selection process.  Does that sound reasonable to you?
> > Ideally, the server would be able to fall back even if a driver returns
> > TRUE for ProbeHardware and then later fails PreInit, but that's even more
> > ambitious.
> >
> > There have been a number of suggestions on the list about how to configure
> > the server's driver selection process.  I'll try to round up some people at
> > XDC and see if we come up with a concrete plan, and then I'll try to free
> > up some time to help implement it.
> >   
> As a long term goal this sounds great to me.  I'd like to have a short
> term solution as well though if at all possible.  Knowing the 6 month
> cadence that distributions such as Ubuntu & Fedora are running on, it
> would be nice to have an "upstream supported" short term solution that
> can be ripped out when the server's driver selection process has improved. 

Hi Mario,

Sorry for the very slow response.  We've been swamped with other work and
this slipped through the cracks.

Given that this is a distribution bug due to
  a) the fact that they're using PCI ID match tables in the first place
     instead of letting the X server choose a driver and
  b) the fact that their PCI ID table generation scripts don't generate a
     complete table,
it seems better to just fix the distribution packages to generate more
comprehensive tables until they can fix (a).  I don't think distributions
should be afraid to implement distro-specific fixes for distro-specific
problems like this one.

> As the situation stands today, if you try to boot some recent NVIDIA
> hardware on the latest Ubuntu 9.10 or Fedora 12 snapshots (which are
> about as close to upstream code as you can get), you'll end up with no
> X.  So how would you feel about adding in the solution I presented (or

This shouldn't happen, it should fall back to the vesa driver.  Does the
vesa driver not work for some reason?  That seems like an unrelated and
bigger problem.  If you have more details (e.g. failure logs), feel free to
file a bug and I'll try to take a look at it.

> something similar) at least until you have agreement from the other X
> developers and have a more permanent solution in place?