Re: Prefer nvidia over nv when available
On Fri, Oct 05, 2007 at 09:38:38AM +0200, Free Ekanayaka wrote:
> Hi David,
>
> |--==> David Nusinow writes:
>
> [...]
>
> DN> The idea for the future is that all the drivers will export a symbol table
> DN> of the PCI ID's they support. The server will scan them for drivers
> DN> supporting the required PCI ID. My plan is to have them export an
> DN> additional symbol table consisting of driver names that they override. So
> DN> nvidia would export an override table with "nv" in it.
>
> Cool, pretty much like kernel some modules then.
>
> DN> The notable thing about this is that it exists entirely outside the
> DN> packaging system, so it's entirely up to upstream.
>
> That is a Good Thing :)
>
> DN> In the case of the
> DN> various nvidia drivers, if the legacy drivers are updated to include these
> DN> symbols then they'll be automatically loaded if they're available. If not,
> DN> then the server will load something else (nv if available, or an
> DN> arch-specific fallback like vesa if not).
>
> DN> So, if Nvidia decides to update their drivers, they'll get the benefits of
> DN> this.
>
> Let's say that, in the best case scenario, that Nvidia updates both
> their new and legacy drivers (71xx,96xx). Still the relevant Debian
> packages can't be installed at same time (as they are now), so the
> proper nvidia driver sporting the proper PCI ID might not be available
> on the system. Is there a workaround for this?
I have two related solutions in mind. One is that the server will ship a
list of PCI ID's mapped to drivers itself. This list would allow the server
to inform the user via a log what driver they would install. We could
easily patch this to add the nvidia id's if we want. I don't know exactly
what form this will take though.
The second solution is to use discover. We're trying to get rid of it, but
it's being repurposed for Debian to allow custom package installs for the
hardware it's installed on. We may end up wanting to hook it in to d-i to
allow the user to just install the driver they want on install. We could
teach it about the nvidia legacy drivers.
This is still more fantasy than reality, although I think they're good
long-term goals to shoot for.
> For example in the Debian package for a legacy driver one could change
> the path of the file of the nvidia xorg driver, from:
>
> /usr/lib/xorg/modules/drivers/nvidia_drv.so
>
> to
>
> /usr/lib/xorg/modules/drivers/nvidia_drv-96xx-.so
>
> so that the package doesn't conflict anymore with the other nvidia
> driver packages. Or other tricks like this one.
>
> Would this work/make sense?
I'm not sure if this would work because the driver also ships its own
version of the glx. If they require different glx's then they'd conflict. I
don't know the details of the nvidia driver to say for sure though.
> DN> The PCI ID symbol table thing already exists upstream in the xserver
> DN> master branch, but the code to auto-load the driver based on it doesn't
> DN> exist yet, but that's my goal for next week. In the worst-case scenario,
> DN> Nvidia won't add the necessary symbols and users will just have to edit
> DN> their xorg.confs the same way they did in the past.
>
> In the worst case scenario of Nvidia not updating their drivers (or
> updating only the new one and not the legacy ones), what could be done
> to avoid the user to edit directly the xorg.conf file?
Well... I do have a set of patches currently in unstable that could
theoretically handle this. Instead of relying on the module itself to carry
the symbols, they use a flat text file list of PCI ID's. I was going to
remove this system in favor of the symbols system, but I could leave it in
place as a secondary fallback mechanism for just this sort of thing. Then
you just have to have the package ship the text file and you're done. It
might be worth doing, although the extra cruft just to support non-free
drivers kind of sucks. I'll try to discuss it upstream and see what they
think.
- David Nusinow
Reply to: