I'm also still using 304.xx driver, so i will keep updating my SlackHacks with patches that worked with newer kernels :)

Thanks for Y'alls work and tips on this. One of our devs has built the 304.108 package stack with support for 3.11 kernels and these are now in OpenMandriva repos.

For anyone interested, I have just fully updated a system to Slackware 14.1 release status and found Nvidia 304.116 was available.

I first uninstalled the 304.108 before updating the system with slackpkg, and manually updating the kernel to 3.12.17 generic-smp.

After playing with nouveau for a while and finding that using accel resulted in system freezes, I installed the 304.116 unpatched - works great!

Astrogeek let us know what display card you have. I do know that during the 304 then 310 and up there was many changes for the 600 and 700 series keep us posted how well it functions thanks.

Sorry, I should have included that -

On an AMD Phenom II - 32bit Slackware.

I really want to use the nouveau, but when I enable accel firefox crashes and freezes the entire system - the only way out is a hard reset. I don't game but VLC and a few other things need it. But I must say that my nvidia experience has been much improved since 304.108 and now 304.116 is really smooth.

Just out of curiosity, is there some benefit to running the 304 branch over the 331 branch? I see that the 304 is a legacy branch and the 331 is a long tern support branch. I am confused because my GTX-460 is supported on both branches.

Thanks.

For myself, the 6150SE is only supported in the 304 branch.

I just looked and the GTX 460 is indeed supported in the 304 and 331 branches, so apparently there is some overlap. But I would guess that the 331 branch get better support - performance updates - whereas I think the 304 only gets kernel and bugfix updates, as I understand it (but admittedly I don't know much more than how to get my own systems going).

You can expect nVidia's long-term driver support actually being better than most open source drivers. FOSS drivers tend to bit-rot after three to five years, because even their developers replace their hardware and don't test their code on ancient stuff again.

Nouveau is working hard on improving GTX 600/700 support and if they break the age-old C61 driver by accident, they most likely will not notice. You can & should do a bug report at nouveau, buy I doubt, that it will get a high priority.

So an official vendor-supported legacy driver may be the better choice.

The current driver branch only supports nVidia G80 GPUs and later. The reason for spawning legacy branches is to avoid breaking code for older GPUs while implementing new stuff for new GPUs.

Of course, there is no reason for removing support of the GTX 460 from the legacy branch, when it was already in there.

That is what happens with the nVidia drivers.

173.XX is for the 'FX' series (GF 5XXX) but will also work with GF 6XXX, 7XXX and 8XXX CPUs.

304.XX is for GF 6XXX to 7XXX (so they will run with both the 304.XX and 173.XX drivers).

310+ is for GF 8XXX and newer. All 8XXX and newer cards will run with both 304.XX and 310+ ;)

The funny thing is that with the 8XXX cards you now have the choice of 3 drivers :D

I also have the 6150 SE in my tower and saw that there's a new driver available. So far the 304.108 works fine with 14.1. I'll download the newer driver and install that later.

Just installed the latest NVidia 304.116 and it works fine :)

Same here. The new driver works just fine on my system as well.

Well I can Honestly say with the 3.12 testing kernel none of the patches work for me none of the patched nvidia stuff those are the official nvidia patches for several different drivers.
seems Nvidia is more in to android. and may be time to look for a AMD card.

Makes you wonder why all the consoles will be getting AMD.

Newest NVidia driver is ready for 3.12 without any need to patch: http://rglinuxtech.com/?p=924

Well, I think this thread is about legacy GPUs using the 304.xx drivers.

For more recent NVidia GPUs the latest working drivers are 319.49 and 325.15.

the 304 builds fine in 14.0 and 13.37 and there stock kernel. 14.0 to 14.1 we have seen some very big changes in the xorg and mesa programs
I am sure things will come about. the 304 driver works well on my GT 640 2gb ram in the previous environments.
right now the 319.49 builds with the 14.1 and if I go to the 319.60 it builds but breaks all my video capture and breaks all my video software using libva.
and ffmpeg. there is other drivers that do build and work but still breaks my software.
This is not good or bad just data.
I patched the 304 and the build failed I am still looking into it. I am only using the 3.12 testing config until Pat sets out another kernel to test
then I will try it.
One kernel at a time.

Just updated one box to 304.119 - installed unpatched and works just like 304.116 as far as I can tell on first looks.

I have been experiencing a small problem since I replaced my monitor with a new "widescreen" thrift-store treasure, 1368x768. About every third or fourth time I start X it comes up in the wrong resolution, once in a while offset on the screen or the monitor reports "no signal".

I am using Fluxbox, I include the nvidia-settings.rc in the startup script and I have the correct modeline in xorg.conf. I was hoping 304.119 might fix it, but alas... (might not be an Nvidia problem).

For now I wrote simple xrandr script in my home directory which I can invoke even when blinded by no signal, and it seems to reset fine. I can also exit Fluxbox or Ctl-Alt-BS and kill X. More annoying than anything else.

Are sure that it is correct? Why don't you let the driver use the modeline from the EDID?

I added the modeline while trying to fix this behavior, which did not change anything but I left it there. Before I added it I would guess the driver was using the EDID values (although I am far from an expert in how that all works).

I originally had a Dell 1024x768 (?) monitor. It never came up with the wrong resolution, but once in a while it would fail when X started. I tinkered with it a few times but never got a handle on it and mostly ignored it and restarted X when it happened. Then I got an Acer 1368x768 which I really like (easy on my eyes and extra width that still fits on my crowded desk). It has the more frequent problem of starting at incorrect resolution, and sometimes fails with "no signal" as did the Dell, so I expect they are the same problem.

Today I saw there was a new Nvidia driver for it so I installed it thinking it "might" be an Nvidia problem, but no change.

Additional info: It is a GeForce 6150SE video controller, the problem occurs with or without the nvidia-settings loaded from the Fluxbox startup script, and with assorted startx options that I have tried at various times. In short - nothing I have done has seemed to make any difference.

All of that said, I am not in very active pursuit of a solution at this point, but as you were kind enough to reply - thanks! Any guidance or suggestions will be appreciated.

If the built-in EDID modeline doesn't work, there is a good chance, that just your display is broken. You should remove the modeline, because it overrides the defaults which work best with your display, especially if the modeline doesn't help anything.

Which display connector do you use? Did you try a different one?

I'll comment out the modeline - it did not change anything.

I am using the VGA connector and yes, I have tried a different cable.

At times over the past few months I have tried to troubleshoot it and read much and tried several things along the way. It might just be a hardware problem, either in the monitor or the computer. It is not "flakey" in any other way, but this particular problem has been like gravity - nothing else seems to interact with it. Hence, my decision to mostly just live with it.

I'm bumping this thread just to ask if someone has successfully installed either the 304.108 or 304.121 Nvidia's driver along with the 3.13 Linux kernel ?

121 should build against kernel 3.13.x and Xserver 1.15... Are you having trouble with it?

I don't know at the moment.

I'm just considering compiling a 3.13 branch kernel because of the enhancements of the snd_usb_audio module of the Linux kernel.

newer kernel in -current tree: 3.14.3
anyone can confirm that 304.121 works with this kernel?

Regarding modelines - Some monitors, especially some earlier HDTVs, have horrible EDIDs and must be overridden. We can't always assume X will figure it out.

Regarding consternation - AMD has worse support for legacy video cards than nVidia, although the FOSS drivers are often better than nouveau on nVidia.

Someone pointed out that FOSS video drivers for ANY legacy video card, regardless of manufacturer, tend to "go south" over time because the devs have upgraded their hardware and no longer can properly maintain. This should be a lesson. If newer video cards are available for your platform it is just easier and most often a delightful improvement to upgrade and some very decent video cards are quite cheap. It is not at all uncommon for a $60 modern card to outperform a $200 card from 5-7 years ago. Many will reduce the load on your also aging CPU as well.

i can confirm 304.121 worked without any patch for Linux Kernel 3.14.3 :)

I've been using 319.82 for a while now as anything newer than that introduces tearing to 'xv' video on my box, but that only works up to 3.12.y (or 3.13.y using an unofficial patch). Think I'll give the 304.xx drivers a go and see if they're also tear-free. Will likely be easier to keep updated if they work for me.

Legacy open source code can break just by recompiling it. So even with FOSS drivers, the better strategy would be keeping the known-good binaries around and plug them into stable interfaces. This is how commercial closed source OSes handle this.

Sadly with "modular Xorg" this isn't possible and that makes the whole "modularity" a joke. In the early days of monolithic X11, you just had to keep a working X server binary around...

That is only an option for a minority of all PCs. Most GPUs are integrated (notebook etc.) and even if you have an expansion bus available, it is already outdated (like AGP) by the time the driver bit-rot problem surfaces.

Thankfully it is doubtful that PCIe will be saturated for many years. Hopefully more notebook manufacturers will plan for this, or already are, and will provide notebook users with an upgrade path for graphics.

In most modern PCs PCIe isn't used anymore for graphics, because the graphics processor is integrated directly into the CPU.
Most notebook manufacturers want to sell non-upgradable thin and light devices together with mainstream operating systems. These OSes don't have GPL issues and provide stable driver interfaces. The hardware manufacturers don't care about self-induced binary driver breakage in niche platforms.