NVIDIA Updates Legacy Drivers With X.Org Server 1.19 Support

[phoronix]

Phoronix: NVIDIA Updates Legacy Drivers With X.Org Server 1.19 Support

In addition to NVIDIA releasing the 378.13 big feature release, this morning they also announced updates to their two legacy drivers...

http://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-Legacy-6-Fermi-1.19

[dungeon]

What these two legacy driver releases provide are support for X.Org Server 1.19 (X Server ABI 23) and a fix for a bug in the NVIDIA installer for loading kernel modules built against non-running kernels.

I think i already saw this... yup, they already said the same for 304.134. two months ago:

http://www.nvidia.com/download/drive...x/112990/en-us

So 5 is bumped and that is about it

[Amarildo]

Meanwhile, AMD GCN users (which are way more recent than NVIDIA's Legacy) stayed almost an entire year with the same Xorg and Kernels officially supported because AMD cut development of fglrx/Catalyst and didn't bring it to the AMDGPU-PRO driver, which is still not supporting all cards correctly.

[smitty3268]

Meanwhile, AMD GCN users (which are way more recent than NVIDIA's Legacy) stayed almost an entire year with the same Xorg and Kernels officially supported because AMD cut development of fglrx/Catalyst and didn't bring it to the AMDGPU-PRO driver, which is still not supporting all cards correctly.

Only if you ignore the Mesa drivers.

[Amarildo]

Only if you ignore the Mesa drivers.

The problem is that Mesa is very short on developers, so it's often buggy and still lacks features such as a graphical user interface, OpenCL, and so on. Let's not forget the nasty hang problem (with TF2, XCOM, X-Plane, etc) that lasted almost a year as well, while fglrx/amdgpu-PRO were working fine all year long.

I'm all in for OSS drivers, but AMD has proven to not take all their actions and decisions correctly. While they're pissing at their customers doing half-baked cakes, NVIDIA users have all features working, all games, every recent version of Xorg and the Kernel, CUDA, and better performance overall.
With AMD, not only the release cycle is moronicly long, they didn't even have the decency to update fglrx so that it would support newer Xorg/Kernels.
In the end, I don't care if the driver is open, I care if it works; if it doesn't, I kiss the mf goodbye. That's why I went over to Windows and stayed there for a little over a month, because the scenario in AMD-Linux is deplorable for me. The only reason I got back to Linux is because I don't like Windows' ecosystem, but TBH I'll probably end up there again and again and again. That is, if until my next upgrade AMD didn't fix their crappy drivers, otherwise I'll just go with NVIDIA despite hating their guts.

[smitty3268]

The problem is that Mesa is very short on developers, so it's often buggy and still lacks features such as a graphical user interface, OpenCL, and so on. Let's not forget the nasty hang problem (with TF2, XCOM, X-Plane, etc) that lasted almost a year as well, while fglrx/amdgpu-PRO were working fine all year long.

I'm all in for OSS drivers, but AMD has proven to not take all their actions and decisions correctly. While they're pissing at their customers doing half-baked cakes, NVIDIA users have all features working, all games, every recent version of Xorg and the Kernel, CUDA, and better performance overall.
With AMD, not only the release cycle is moronicly long, they didn't even have the decency to update fglrx so that it would support newer Xorg/Kernels.
In the end, I don't care if the driver is open, I care if it works; if it doesn't, I kiss the mf goodbye. That's why I went over to Windows and stayed there for a little over a month, because the scenario in AMD-Linux is deplorable for me. The only reason I got back to Linux is because I don't like Windows' ecosystem, but TBH I'll probably end up there again and again and again. That is, if until my next upgrade AMD didn't fix their crappy drivers, otherwise I'll just go with NVIDIA despite hating their guts.

Uh huh.

Like i said, the drivers supported new Xorg and kernels.

[SilverMachine]

Wish AMD would take this as an example. They really should.

[agd5f]

Here is a prove for that. This site points to kernel.org that has the half-implement (see the diff column and compare to agd5f 4.11-wip kernel) amdgpu driver.
http://developer.amd.com/tools-and-sdks/open-source/

I'm not sure I understand what you are getting at. I have a wip kernel tree for every kernel release (4.7, 4.8, 4.9, etc.). They contain code that is going upstream in the next kernel cycle. The code in 4.11-wip is going upstream in 4.11, the code in 4.12-wip will go upstream in kernel 4.12. That is how kernel development works. There will always be a delta of stuff that is on its way upstream.

[dungeon]

agd5f

He thinks that these branches are more stable than released kernels on kernel.org. So i guess upon testing and proving that those "works for me" he decided to recommend them to anybody... Same way also anybody who use kernels from kernel.org is wrong.

At least that is how understand him, so kernels from kernel.org are per him always half baked, but your branches are always full baked and when someone say "recent amdgpu" debianxfce jump right on him and say no that is not recent kernels from kernel.org are not recent, people should use your brances to be recent and stable... And not only that, he also think that AMD developers should start recommending these to anybody.

Also whoever does not agree with him is an idiot, because he can't be wrong

[Amarildo]

dungeon I do believe agdf5's Kernels are very stable too. I did a 'git diff' between a current grsec patch (at the time) and agdf5's 4.7-staging Kernel, and I was surprised: despite being labled "4.7", agdf5's Kernel is somewhat comparable to linux-git: it was not as "old" as 4.7, it had the latest drivers, AND had a ton of security and other patches backported.

IMO agdf5's Kernels should be an official branch at Kernel.org.