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

[Fabio Massimo Di Nitto]

On Tue, 14 Sep 2004, John wrote:

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

Everything is possible, it's only a matter of time. Right now my focues
are on warty. For hoary we will not even have a X server but some kind of
virtual reality 3D system plugged into our brain... who knows...

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

welcome to the club :-)

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

No dual head system can't be autoconfigured at the moment and this is
something we planned to investigate in future. It is not a short term
feature goal.

> >>>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't know 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).

That's why we attempt all kind of known-to-work autoprobe before asking a
question (at least this is possible in X). If autoprobe fails there is no
other option than ask the user.

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

For hoary the story is totally different also because we will stop using
xfree86 and that basically will require a full repackage starting from
scratch. Here we have been working with packages coming from Debian that
have been designed with a different user target. There have been a lot of
improvements in them.

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

No for warty.

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

If you are thinking to some sort of driver "wrapper" to keep compatibility
with both, we already had this idea but it is something that will require
upstream help. It goes far behind my knowledge.


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

Probably we are talking about 2 different things. I am talking about X
config file. Each driver has a bunch of options that can be configured. nv
and nvidia are not the same. In case a user implements a very complex and
peculiar configuration of the nv driver, we are not sure that the same
config can/will work with the nvidia driver and viceversa.

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

We are increasing the amount of packages involved into it to 6 or so :-)))


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

see my previous comment :-)))

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

This is probably worth a discussion on its own since it involves all
system run levels.

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.