DVI output, ATI or nVidia

[Lonni J Friedman]

On 6/27/07, Dr. Michael J. Chudobiak <mjc at avtechpulse.com> wrote:
> >> Hmm, I didn't order my Intel GPU direct from Intel either, but I can
> >> still access the driver bugzilla. I guess you finally have some evidence
> >> of how open source support can be better.
> >
> > Different perhaps.  I don't see how that makes it better other than
> > listing hundreds, if not thousands of bugs that haven't been fixed,
> > and may never be fixed.
>
> Well, a list of unfixed bugs would tell you what bugs were real, how
> common they were, who you could contact to see if workarounds were
> found, what level of development is occurring, and whether your
> particular issue is likely to be addressed any time soon.

All of that information is already readily available via the methods
documented in the NVIDIA driver README (and on its website).

> > I'm sorry but I'm not following you here.  Are you stating that having
> > the source for the driver allows you to plan your hardware
> > requirements?
>
> No. I'm saying that in my experience, dealing with the hardware quirks
> and limitations imposed by the intel driver are easier to manage than
> the software quirks of the closed drivers.
>
> Once you know you need DDC/DI, you buy NEC Multisyncs (or whatever).
> Problem solved. (And the driver developers have indicated that the
> DDC/DI requirement will be removed in the future, incidentally.)

I'm still amazed that you gloss over this nasty hurdle as if its
trivial.  If i've just spent a non-trivial amount of money on a
display, it should damn well work with my GPU.  Why would anyone even
think that this limitation would exist?

>
> Binary drivers and open kernels, however, make a square peg <> round
> hole system. It's just hard to maintain over the long-term.

Considering how flawed your example above is, this seems like the pot
calling the kettle black.

> > I'm not even making that argument.  I'm just saying that people are
> > seemingly unaware that the market segment which finds Intel's graphics
> > offerings sufficient is a rather small segment from a revenue
> > perspective.  Most people are unaware of the fact that desktop usage
> > is not where most companies get the bulk of their revenue, other than
> > by sheer volume.  Its done either by quantity or quality.  And no, i'm
> > not implying that Intel's drivers or hardware are low quality, just
> > that they are going on quantity to make money.
>
> OK, nvidia doesn't want to spend the effort on a decent open source
> driver because the market isn't worth it. That's fine, and that's
> nvidia's call. But for the linux user, it sucks, and Intel's approach is
> better - for the average, non-movie-editing user. The nvidia approach
> only benefits power video users. Let's not pretend that nvidia is a good
> solution for the typical user.

You can pretend whatever you'd like.  I'm basing my statements on reality.

> > Can't or won't?  I've seen many kernel backtraces from systems that
> > happened to have closed source drivers on them, where the backtrace
> > never even made a passing reference to the closed source driver and
> > the developers refused to look at it.  Sure, there's a chance that the
> > closed source driver contributed to, or even caused the problem, but
> > there's an even better chance that it was completely uninvolved.  This
> > stance seems more to do with religious zealotry than technical
> > limitations.  And its certainly their right to stand up for their
> > principles.  However, hiding behind them is something entirely
> > different.
>
> Hmm, kernel developers are religious zealots and I'm a fan boy. Did you
> run this past the PR department? :-)

I'm not speaking for my employer anywhere in this thread.  I'm
speaking for myself.

>
> The kernel developers are busy, why should they cooperate with you if
> you won't cooperate with them?

No where was I asking any kernel developers to "cooperate" with me.
If random Joe User is having a problem, random Joe User shouldn't be
punished by kernel developers.  Or at the very least those kernel
developers should be honest about why they don't want to debug the
problem, rather than hiding behind a "binary driver, we can't debug
this, go away" statement.