On Wed, 31 Dec 2003, Tomas Szepe wrote:
> On Dec-30 2003, Tue, 18:46 -0600
> Derek Foreman <[email protected]> wrote:
>
> > His primary requirement was that it (the motherboard) work well with
> > linux. He stated that he was capable of installing drivers if he had to,
> > but it would be even better if it wasn't required.
> >
> > Open source drivers, or whether nvidia fits your idea of a "linux
> > supporting company" were not on the stated list of requirements.
>
> Indirectly they were, if you admit that opensource drivers are "better"
> for Linux users. The person's goal was, let me quote, "to make sure
> I get the hardware that works best with Linux." I suggested they avoid
> nVidia, because _my opinion_ is that binary-only drivers do not "work best."
I think we're just going to have to disagree on what "work best" means. I
choose to interpret it as a measure of driver functionality and
performance.
Your definition of "work best" is based on a political agenda, and not on
technical merit.
> > There are a lot of drivers in the linux source tree itself that are
> > just as closed to you and I as the nvidia ones. Lots of companies only
> > give out their documentation under NDA to "appropriate open source
> > developers" (I thought one of the great things about opensource was that
> > everyone was an "appropriate developer"). So while we can look at the
> > source code, we don't have enough information about it to provide adequate
> > peer review or to fix bugs in it ourselves.
>
> Now, excuse me French, _this_ is a big load. Come back when you've tried
> to find out how a piece of hardware works with and without working driver
> sources.
Excuse you indeed. I have.
> > We still have to contact whoever has the complete documentation, and we
> > still have to wait for them to make a fix available.
>
> Ok, I might not be able to add support for a new revision of a chip,
> true enough. Somebody will do it, eventually. The important thing
> you're ignoring is -- if such a driver is oopsing my box, I will be
> able to fix it.
You will be able to fix a certain subset of possible problems. Maybe you
can fix an OOPS or BUG if they're obvious enough, and have to do with
kernel interfaces and not the hardware itself.
If the driver is not properly accessing the hardware, and you don't
have the documentation, it's as much a black box to you as nvidia.o.
> > Just claiming "nvidia translates into trouble" is really nothing more
> > than FUD.
>
> No, it isn't. Search the lkml archives for "OOPS Tainted nvdriver."
Of course it is. And you're doing it again. Performing that search
doesn't give any evidence that "nvidia is trouble", or even that their
graphics driver is unstable. But the implication is that nvidia's drivers
will cause me problems.
This is getting quite unfocused. My intended point is that saying "<foo>
is trouble" without any detail at all is misleading. It gives the
impression that <foo> may not operate correctly, when the real issue at
hand here is that it is closed source.
Derek Foreman wrote the following on 01/01/2004 07:15 AM :
>On Wed, 31 Dec 2003, Tomas Szepe wrote:
>
>
>
>>On Dec-30 2003, Tue, 18:46 -0600
>>Derek Foreman <[email protected]> wrote:
>>
>>
>>
>>>His primary requirement was that it (the motherboard) work well with
>>>linux. He stated that he was capable of installing drivers if he had to,
>>>but it would be even better if it wasn't required.
>>>
>>>Open source drivers, or whether nvidia fits your idea of a "linux
>>>supporting company" were not on the stated list of requirements.
>>>
>>>
>>Indirectly they were, if you admit that opensource drivers are "better"
>>for Linux users. The person's goal was, let me quote, "to make sure
>>I get the hardware that works best with Linux." I suggested they avoid
>>nVidia, because _my opinion_ is that binary-only drivers do not "work best."
>>
>>
>
>I think we're just going to have to disagree on what "work best" means. I
>choose to interpret it as a measure of driver functionality and
>performance.
>
>Your definition of "work best" is based on a political agenda, and not on
>technical merit.
>
>
>
Linux isn't a closed-source system where binary APIs are frozen, so
working best with a set of specific kernels (and I don't even say kernel
versions, I *mean* kernels, just search for threads on nvidia with
kernels built with some perfectly legit gcc flags) doesn't mean it is
working best with Linux.
What if Nvidia goes bankrupt in the future like 3DFX did, what do you do
with your card ? throw it away ?
I type this e-mail on a Sony PCG-GRT785B laptop which happen to use a
Geforce Go 420 chip. Until the 5328 nvidia driver, I couldn't even
switch to a text console after starting X (search for this type of
problems and you'll see that the laptop support is really lacking in
their drivers). Even now software suspend is out of the question when
the nvidia kernel module is loaded (even with X stopped). I was aware of
the fact that I could encounter these problems when I purchased the
laptop and was ready to use the OSS XFree driver without 3D support
(unfortunately I found out that the ones shipped with RH9 don't work),
so I assume them, but it's hardly what I'll call "working best"...
There's nothing political in saying that binary drivers don't work best.
In fact it assumes a minimum understanding of the technical aspects
involved in a Linux kernel to understand *why* they can't work best...
--
Lionel Bouton - inet6
---------------------------------------------------------------------
o Siege social: 51, rue de Verdun - 92158 Suresnes
/ _ __ _ Acces Bureaux: 33 rue Benoit Malon - 92150 Suresnes
/ /\ /_ / /_ France
\/ \/_ / /_/ Tel. +33 (0) 1 41 44 85 36
Inetsys S.A. Fax +33 (0) 1 46 97 20 10
El Thu, 01 Jan 2004 18:04:07 +0100 Lionel Bouton <[email protected]> escribi?:
> Linux isn't a closed-source system where binary APIs are frozen, so
> working best with a set of specific kernels (and I don't even say kernel
> versions, I *mean* kernels, just search for threads on nvidia with
> kernels built with some perfectly legit gcc flags) doesn't mean it is
> working best with Linux.
> What if Nvidia goes bankrupt in the future like 3DFX did, what do you do
> with your card ? throw it away ?
Yeah! I own a voodoo 3 3000 card. I've 100% opensource drivers. Under
windows XP, I suffer from hangs while playing some games. And looking
at the memory dump, the reponsible is the graphics driver, which
isn't updated just because tdfx has dissapeared, hence my voodoo card
is condemned to hang my box forever under windows.
And if anyone had a tdfx card in a powerpc machine, they could use it.
Unlike the propietary drivers: you have to use the framebuffer in your
ibook (with linux) because you don't have drivers for PPC. However,
Mac OS X has them....
On Thu, 2004-01-01 at 19:04, Lionel Bouton wrote:
> Derek Foreman wrote the following on 01/01/2004 07:15 AM :
>
> >On Wed, 31 Dec 2003, Tomas Szepe wrote:
> >
> >
> >
> >>On Dec-30 2003, Tue, 18:46 -0600
> >>Derek Foreman <[email protected]> wrote:
> >>
> >>
> >>
> >>>His primary requirement was that it (the motherboard) work well with
> >>>linux. He stated that he was capable of installing drivers if he had to,
> >>>but it would be even better if it wasn't required.
> >>>
> >>>Open source drivers, or whether nvidia fits your idea of a "linux
> >>>supporting company" were not on the stated list of requirements.
> >>>
> >>>
> >>Indirectly they were, if you admit that opensource drivers are "better"
> >>for Linux users. The person's goal was, let me quote, "to make sure
> >>I get the hardware that works best with Linux." I suggested they avoid
> >>nVidia, because _my opinion_ is that binary-only drivers do not "work best."
> >>
> >>
> >
> >I think we're just going to have to disagree on what "work best" means. I
> >choose to interpret it as a measure of driver functionality and
> >performance.
> >
> >Your definition of "work best" is based on a political agenda, and not on
> >technical merit.
> >
> >
> >
>
> Linux isn't a closed-source system where binary APIs are frozen, so
> working best with a set of specific kernels (and I don't even say kernel
> versions, I *mean* kernels, just search for threads on nvidia with
> kernels built with some perfectly legit gcc flags) doesn't mean it is
> working best with Linux.
> What if Nvidia goes bankrupt in the future like 3DFX did, what do you do
> with your card ? throw it away ?
>
The point which you and some of the others that maybe did not use
2.5.* on systems with nvidia cards, is that only the very specific
hardware calls is closed source (nvidia.o), the rest (kernel interface,
agp, vm, etc) is done with source that you need to compile. Thus we
already (thanks to great work from a few guys at minion.de) used
a 2.4 driver with 2.5. Also, a lot of 2.5/6 bugs, and guess what,
even 2.4 vm bugs was fixed, because we had most the source.
I even used it later with 2.5 and NPTL (when the first versions of
the GLX part that supported TLS came out), and to be honest, I have
had very little problems. If I could not fix something myself, it
was usually very quickly fixed minion.de side. Sure, maybe I am
just lucky (or maybe its because I do not use AMD, or VIA chipset
mobo - bug that is another story :D), but the fact is that for a
_lot_ of us out there, we had nVidia cards going 3D, while the
DRM/DRI was in a state of flux. To be honest, _I_ have not had
much success with DRI in general. If I could get it to work (this
means it actually initializes, and glxgears/glxinfo seems to use
direct rendering) with the SIS box at work, or with an ATI card
I borrowed, it would create artifacts, lockup, or such. You do
not hear me going off about DRI on the list?
On the other hand, it seems you had issues :/ Maybe check that
you did not use rivafb - I never had issues like yours *shrug*.
I guess the point Derek wanted to make, and where I want to fill
in, is that you cannot say for a fact that something will work,
or not for all. For some, the nvidia drivers works great, and
if you are into games, it will prob give better performance. For
some it wont. For some DRI works, for others, not. And the 'its
a binary driver, so you cannot debug/fix it' does not hold the same
as it used to these days with the new types of ati/nvidia drivers.
If you are a 'open source fanatic', please keep your wits with you,
and do not try to get everything into a 'closed source is evil'
argument. I am sure most of us are to some extend fanatic about
open source, but there is a time and a place. The fact is, unless
something drastically happens to the commercial sector, we will always
have companies that do not want to fully release all specs, as they do
not want to loose their 'edge' - but you do not have to support them,
right?
Hey, its Linux - we have the choice, right? Unfortunately it seems
that some still want to take that choice from others :/
<ramble/>
--
Martin Schlemmer
Thanks for cutting down on the CCs, this is getting out of hand.
On Thu, 1 Jan 2004, Lionel Bouton wrote:
> Linux isn't a closed-source system where binary APIs are frozen, so
> working best with a set of specific kernels (and I don't even say kernel
> versions, I *mean* kernels, just search for threads on nvidia with
> kernels built with some perfectly legit gcc flags) doesn't mean it is
> working best with Linux.
There are features available in both the ati and nvidia closed source
drivers that are not available in DRI. If I want "full use" of my
hardware, then DRI is does not "work best" for me.
Regardless, I should not have used the word "political" in my response to
Tomas.
> What if Nvidia goes bankrupt in the future like 3DFX did, what do you do
> with your card ? throw it away ?
What would probably happen, as has happened with the aureal vortex, is
that someone would maintain the open source wrapper. Possibly until
someone reverse engineered the driver (as happened with the aureal vortex)
- but I wouldn't hold my breath on that for something as complicated as a
graphics card.
> I type this e-mail on a Sony PCG-GRT785B laptop which happen to use a
> Geforce Go 420 chip. Until the 5328 nvidia driver, I couldn't even
> switch to a text console after starting X (search for this type of
> problems and you'll see that the laptop support is really lacking in
> their drivers). Even now software suspend is out of the question when
> the nvidia kernel module is loaded (even with X stopped). I was aware of
> the fact that I could encounter these problems when I purchased the
> laptop and was ready to use the OSS XFree driver without 3D support
> (unfortunately I found out that the ones shipped with RH9 don't work),
> so I assume them, but it's hardly what I'll call "working best"...
Is nvidia aware of this issue? If you're forced to keep that laptop, it
might be worth your time to bring it up with them.
Better would be to return the laptop and follow Joel Jaeggli's advice
from earlier in this same thread, but unfortunately that's probably not an
option.
> There's nothing political in saying that binary drivers don't work best.
> In fact it assumes a minimum understanding of the technical aspects
> involved in a Linux kernel to understand *why* they can't work best...
The closed source modules "work best" for me, as some of the code I play
with uses vertex buffer objects.
I realize that tomorrow nvidia could drop linux support, next week someone
could discover that echo HI\ MOM > /dev/nvidiactl gives them a root shell.
But for my situation, these things are an acceptable trade for the added
toys.
Derek Foreman wrote the following on 01/01/2004 10:44 PM :
> [...]
>
>There are features available in both the ati and nvidia closed source
>drivers that are not available in DRI. If I want "full use" of my
>hardware, then DRI is does not "work best" for me.
>
>
>
We could argue endlessly on that subject. Let's agree that what
*practically* works best for one doesn't automatically for another. My
"best" in "they can't work best" conclusion referred to the utopic
bug-free, adaptable to whatever changes in new kernels happen during the
21st century driver.
>
>What would probably happen, as has happened with the aureal vortex, is
>that someone would maintain the open source wrapper.
>
You can't bet on it. You don't know which assumptions the binary code
part makes on kernel structures' layouts.
> Is nvidia aware of this issue?
Yes they are, a bug report was already filed to them when I searched
before posting mine. For the text mode, according to the nvidia people
answering on their support forums this seems to come from the various
ways hardware are initialised depending on the actual VGA BIOS. For the
software suspend problem that bites me now this is probably the lack of
ACPI support in their driver they are already well aware of but as
swsusp is a patch to the 2.4 (and now 2.6), I don't think they'll take a
bug report seriously anyway.
>Better would be to return the laptop and follow Joel Jaeggli's advice
>from earlier in this same thread, but unfortunately that's probably not an
>option.
>
>
>
This laptop was the best hardware I could buy for the money and my
needs. In fact my problems with the nvidia driver weren't even supposed
to exist as I first planned to go the XFree86 nv driver way (without 3D
support as I don't need it). Unfortunately, the LCD panel isn't setup
properly by the OSS driver version distributed with RH9. I didn't have
time to try XFree86 CVS so proprietary I went...
>The closed source modules "work best" for me, as some of the code I play
>with uses vertex buffer objects.
>
>I realize that tomorrow nvidia could drop linux support, next week someone
>could discover that echo HI\ MOM > /dev/nvidiactl gives them a root shell.
>
>But for my situation, these things are an acceptable trade for the added
>toys.
>
>
>
As I said I agree that "work best for me" is obviously a variable...
My e-mail was only meant to bring some facts to the discussion
describing the problems with proprietary drivers not a "burn all unholy
hardware without proper OSS driver" flamewar starter.
In the hope that will help cool things down a little, best regards and
happy new year,
--
Lionel Bouton - inet6
---------------------------------------------------------------------
o Siege social: 51, rue de Verdun - 92158 Suresnes
/ _ __ _ Acces Bureaux: 33 rue Benoit Malon - 92150 Suresnes
/ /\ /_ / /_ France
\/ \/_ / /_/ Tel. +33 (0) 1 41 44 85 36
Inetsys S.A. Fax +33 (0) 1 46 97 20 10