Games doesent work in Fedora test 3

[Mike A. Harris]

On Wed, 22 Oct 2003, joe wrote:

>Nobody is suggesting that this list troubleshoot nvidia driver issues, 
>that would be pointless, since, as we all know, and as has been 
>repeatedly stressed, nvidia controls the development of their drivers - 
>so let them do what they do best, and report any nvidia driver problems 
>to nvidia - what we do see, however, is users reporting problems with 
>fedora core test, and they are immediately disregarded if it turns out 
>that they are using nvidia cards/drivers - and that is not at all 
>helpful, since the problems they are seeing are seldom if ever related 
>to  any  flaws in the nvidia drivers, from what I can see.

Actually, that isn't the case.  When someone reports an issue 
they're experiencing in X or an X application which is IMHO 
unlikely to be caused by the video driver itself, I routinely 
tell people to report the bug regardless of wether they're using 
Nvidia's proprietary driver. 

For example: Someone just recently reported a problem where a KDE
application's window was not disappearing when they closed it, 
and wondered if Nvidia's driver might be causing it.  Since this 
type of interaction problem is not at the video driver level, I 
would be extremely shocked if it was a video driver problem.  I 
fully expect that it was a bug in the specific application or in 
the window manager, and so I requested they file a bug report 
against that application.  To refuse their problems simply 
because of their video driver, when from a technical perspective 
it would be enormously unlikely the video driver would be to 
blame, would be a bad idea, since the problem they're having is 
most likely to be a problem for ALL users, and not just them.


>>Leaving the analogy for the moment, nobody has presented
>>evidence that the problem is not with the NVidia binary-only
>>drivers.
>
>What sort of evidence are you requiring from them? Most of the time it's 
>something like "reproduce the error without loading the nvidia modules" 
>which makes it impossible to reproduce the error since it only happens 
>in some GUI application :\ Heck, these folks just want to find out how 
>to work around the issues with a minimum of grief. More often than not, 
>it turns out that someone on the list has found a solution and posts it, 
>which fixes the problem for the original poster - no kernel debugging 
>needed,

The bottom line, is that the majority of bugs reported by users 
using Nvidia's binary only proprietary drivers, are due to one of 
the following reasons:

- They did not properly install the Nvidia drivers correctly 
  and/or do not have the kernel modules properly built and 
  installed (although they often THINK that they do, and may 
  argue black is blue to no end about it)

or

- Their XFree86 is not configured properly to use the drivers 
  (although they often THINK that they do, and may argue black is
  blue to no end about it)

or

- They are having Mesa libGL vs. Nvidia libGL conflicts due to
  both being installed simultaneously, or by the Nvidia driver
  installation blowing away various files installed via Red Hat 
  rpms for XFree86.

or

- They are using their own homebrew kernel, and may have any 
  number of problems because of that.

or

- The Nvidia kernel module was not ever built or tested by Nvidia 
  with the particular kernel they are using, and Nvidia 
  themselves might not guarantee or support the particular kernel

or

- One of hundreds of other possibilities.


We do not support the Nvidia proprietary drivers (or any other 
vendor's proprietary drivers for that matter), and it is not our 
responsibility to "prove" that the driver is causing the problem 
or directly involved in the problem.  If we spent our time 
debugging and troubleshooting every single user reported 
bug/problem with proprietary drivers, we'd largely be spending 
99.9% of all of that time debugging users broken driver 
installations and providing free technical support, as well as 
discovering driver/kernel/XFree86 combinations which the driver 
doesn't support, or which the hardware vendor does not support 
nor test.

It is not possible to provide the resources to do all of this 
troubleshooting, when we know right from the start that 99.9% of 
the problems experienced are due to items in the list I posted 
above the majority of the time.  We also know that if a problem 
really is caused by our kernel, or a bug in our XFree86 or 
something else we ship, that either Nvidia themselves, or other 
people in the community will narrow the problem down to that if 
enough people are experiencing the problem.  Once the REAL CAUSE 
of the problem is known, if that cause is in our software, we 
generally will investigate and fix it, however we aren't about to 
dedicate 5 engineers to investigating every binary only driver 
bug report that comes in, just to then have to help the person 
reinstall their driver properly, or use the right kernel, or 
tweak settings in their BIOS, or flash their video BIOS, or ... 
the list goes on.

Unsupported, means 100% unsupported in every way.  Reproduce the 
problem with the "nv" driver after disabling the nvidia driver, 
reinstalling the XFree86 rpms that Nvidia overwrites files in, 
and doing a fresh reboot to reset the video card to it's power on 
state having thus never been touched by the Nvidia X driver or 
kernel module.  If the problem can be reproduced that way, then 
it probably isn't a bug in the proprietary driver.  If it can't 
be reproduced without using the Nvidia driver, then experience 
and time shows, that it generally IS a problem/bug in the Nvidia 
driver or in the user's installation of the driver.

There's nothing Nvidia specific about this however - the same is 
true of all 3rd party drivers, including non-proprietary ones.

>>Do you know of any enterprises who care how well
>>games run on their enterprise desktops?  For most, it's probably a plus
>>if they *don't* run well.
>
>If the games can't run on linux, then it's most likely that no other 
>demanding 3D apps can run either :\

Not necessarily. 3D applications and 3D games generally have very 
different requirements.  Also, demanding 3D apps ran by demanding 
3D users generally require complete OpenGL support and 
compliance, and usually require support that the DRI open source 
drivers do not have and probably never will due to IP concerns, 
patents and other legal concerns companies out there have about 
their IP.   In short, demanding 3D users need to use proprietary 
drivers in order to do what they need to do, so if they're using 
Linux, they really have little choice.  If they need support for 
their drivers, they need to get that support from the video 
hardware vendor that supplied them the drivers.

Do gamers and other end users telephone Microsoft on the phone
and/or use Microsoft bugzilla to report bugs in their binary only
Nvidia drivers they downloaded from Nvidia's website?

I don't think so.

High end corporate 3D users might, but they most likely will 
contact their video vendor directly, whom is the most likely to 
be able to support them regardless of which OS they use.


>>>Surely there is a happy medium here somwhere, and we'll need to find it 
>>>if linux is to gain greater acceptance.
>>
>>Linux is gaining greater and greater acceptance every day just fine,
>>thank you.  
>
>I've been using and administering linux for 10 years, so no need
>to bring me up to speed on that, and the progress has been
>remarkable - but I am far from happy with the rate of adoption -
>take a look around you?  do you see a sea of ms windows pcs?
>Hello? getting hassled by vendors and isps because you're not
>running ms windows? That's far from "just fine" in my book.

I'm very happy with the rate of Linux adoption.  The curve shows 
no signs of slowing down at all.  No complaints here.


>>Put responsibility for solving closed source problems where
>>they belong. That's all I'm saying (albeit, quite verbosely).
>
>We certainly agree on that - and nobody can deny that nvidia has
>been very responsive, and worked hard to make their drivers the
>best ones available for linux. I'm just saying, don't make this
>a witch hunt, give nvidia users the benefit of the doubt unless
>you have some reason to suspect their problem is caused by an
>nvidia bug.

That isn't the way it works.  If the bug is in limbo, then it is 
not our problem.  Someone out there needs to troubleshoot a 
problem to the point where the real cause is known.  We wont 
track down every problem reported just to be able to say "Yes, we 
spent 3 days of one engineer's time debugging this issue for you, 
and we have determined that, like 99% of all other bugs reported 
with that driver, this one also is a bug/problem in the driver."

We don't have engineer resources to throw into the garbage can
like that.  If a problem is not video driver specific, then
depending on the nature of the problem, most likely it is usually
reproduceable with any video driver.  Reproduce it with a 
supported driver on supported hardware, and then it wont be 
considered a bug/flaw caused by the unsupported 3rd party 
proprietary driver.

>BTW I'm running fc t3 with nvidia geforce 2, nvidia accelerated
>drivers, and multimedia applications - it's very snappy, solid,
>and I haven't had any problems so far, other than having to
>tweak a few things to get the GL screensavers to use nvidia
>drivers instead of mesa software gl. I will give it the q3a test
>later.

Great, since the Nvidia proprietary drivers work good for you, we 
should be safe assuming they work perfectly for everyone else 
then.  It should then be safe to assume any problems that people 
experience are due to their own broken installation or 
configuration (which is usually the case).


-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat