What package(s) are needed to install nvidia support ?

[Fabio Massimo Di Nitto]

On Tue, 14 Sep 2004, John wrote:

> >Several reasons:
> >
> >1) the config is complex. a simple sed will not work.
> >
> >
>
> Tougher for the user. To most users, time spend stuffing round with the
> system is time wasted, money lost.

A script to handle it will still have the same limitations that we have
now in handling the config. For example dual head where user might want to
run nvidia on one and nv on the other.. you have no way to read user mind.
This is a corner case of course, but it still a possibility.

>
> >2) if you manually changed the config i can't change it.
> >
> >
> Most users don't.

We can't assume anything. This is the reason why we have to ask questions
at install time or similar.

> >3) the config file belongs to another package that means duplicating all
> >   the code to handle that config file into another package and keep them
> >   in sync. plus it is not nice that package foo modifies package bar
> >   configuration. That means introducing a question to ask the user.
> >
> >
>
> Change the other package to make it easier to make the configuration
> changes needed. You don't have to replicate the code at all.

There are atleast 4 packages involved here. It's not something we can do
for warty. Probably you should trust me when I say that the code needs to
be duplicated. If you are talking for future releases we will have the
time to reinvent the wheel. Not for warty.

>
> >4) it adds another point of failure in the installation system.
> >
> >
> So? Better to get it right than to abandon a group of users. If you
> don't try, you won't get it right.

We can't break things at this point in time. If you think i was abandoning
a group of users, sorry but you are wrong. Again.. now we are focusing on
release. this is an enanchment that will require testing. It can make it
for hoary. The fact that i say "no it's better to leave as it is" is only
for warty simply because changes of these level will not get enough
testing before final.

> >5) the nvidia commercial drivers is not 100% configuration compatible with
> >   the nv free driver. Speaking for my experience on my systems the nv
> >   free driver can go to a higher resolution than the the commercial one.
> >   This means that the behaviour of X will change and that's not what the
> >   user expects.
> >
> Package he X software to accomodate the alternatives.

It does. the nvidia driver fits into X and X can use it. If the nvidia
commercial software is not compatible or uses different options I don't
see why X is at fault.

Actually the nv free driver gives more options than the commercial one
(on 2D of course). Should I remove features from the free one to match the
commercial one?

>
> >>Is it that you think it shouldn't be loaded upon installation or that
> >>performing this loading is likely to cause other headaches?
> >>
> >>
> >
> >It can and did cause headaches. The nvidia driver is splitted into kernel
> >and userland module. First of all loading the kernel module will alter the
> >kernel status (and it is known that was giving problems. see LKML for it).
> >Second we don't want the machine to crash or start behaving weird due to a
> >module that we have no sources and that we cannot fix. The user has to be
> >conscious to do it at his own risk.
> >
> >
>
> Ensure they have an easy way out. Tell them, if a printer is configured
> offer to print out the instructions (the can't read them on the computer
> if it's dead).

The only way out, if the kernel module gives problem is to remove the
module and reboot the machine (if you are lucky to be able to do it
without a powercycle).

As I experienced with the commercial driver also console corruption at
boot time and on the same machine X can't switch to console anymore, even
with paper in the hand, a non-expert user would have problems to boot init
1 remove the driver and reconfigure X.

What would you suggest to do when this happen?

Fabio

-- 
<user> fajita: step one
<fajita> Whatever the problem, step one is always to look in the error log.
<user> fajita: step two
<fajita> When in danger or in doubt, step two is to scream and shout.