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

[John]

Fabio Massimo Di Nitto wrote:

I do not expect Warty to be anything less than,well, covered with warts. 
Rough if you like:-)

Nonetheless, perfection is a worthy goal. I appreciate that there is 
much work to be done, but lrather than say "We cant/won't do that!" say, 
"We will try to do that for Warty+1, Warty+2," or whatever. I'm not 
imposing a timelimit on my suggestions, and I wish you to try to decice 
whether they are feasible.

I've been working with computers since paper tape and punched cards, I 
well understand that software projects take longer than anyone imagines.


>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.
>
>  
>

Dual head systems can, I expect the detected. Do the simple ones first, 
those cover most cases. You can worry about me plugging two outputs from 
my video card into the two inputs to my monitor later.


>>>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.
>  
>

You _can_ assume users don'tknow what hardware they have. I mostly do 
(because I either built it or specced the parts), but not always (some 
of my kit I got at auction; until I try to install Linux on it I don't 
have a clue).

>  
>
>>>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.
>  
>

Do it when you can, but make a decent effort. Sure it's too late for 
Warty; you need some improvements for Hoary, don't you?


>  
>
>>>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.
>  
>

I thought you said, "No."  If you meant "Later," I wish you'd said so.

>  
>
>>>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.
>  
>

You can't change the nvidia, but you probably can work around it.

>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?
>  
>
Why would I suggest that? Have a function that configures one, have a 
different function for the other, and let the mainline choose one or the 
other (or both, with the choice to be made later).

>  
>
>>>>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).
>  
>

That's what I had in mind. When they reboot, they need to be able to 
choose a different path. That may mean a visible grub menu and time to 
respond to it.

>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?
>  
>

Allow the user to choose at boot time to not use the commercial one. See 
my previous para.

I have a system (gigabyte mobo, ATi 9200 SE [Saphire], Via chipset) that 
locks up if I start KDE on the hardware. Recovery requires the reset 
button. The system runs Woody, a runlevel that does not start X (not 
single-user mode) would be very handy.