I'm just going to go ahead and say it : Welcome to 2 years ago
Nvidia's driver issues are hardly new, and hardly contained to the 180 branch. Case in point is my own report comparing Nvidia's 100.14 64bit drivers to ATi's 8.39 64bit release : http://mepisguides.com/Mepis-7/hardw...ati-64bit.html
My biggest beef with Nvidia though isn't the instability and X-server crashes I've lived through. It's the fan control. I literally had to underclock two 6600 GT cards I had because the fans wouldn't shut up, even when the system was at idle. While I've never had to underclock my 7900 GT KO, it's got an obnoxious habit at running the fan at full tilt... ALL the time.
Of course, I could rant about the lack of an Open-Source Strategy from Nvidia, and while I hope that Red Hat's forcing of the issue with NV / Nouveau will result in positive change, I just don't see it happening.
Of course, that doesn't mean I'm looking at AMD/ATi with positive thoughts either. Crossfire support has arrived for the RadeonHD 4x00 series... but what about all the PREVIOUS graphics cards? Crossfire has been around since what.. the x800? Where is that support? Although that's not actually a bug. Although the X-server locking up on certain drag-and-drops on a pair of Crossfired 3870's could possibly be attributed to a bug.
Well, then there's the packaging scripts, with the Debian packaging scripts appearing to be broken. Well, all insult intended, last I heard a Ubuntu guy was handling the Debian scripts, and Ubuntu has no interest what-so-ever in compatibility, a lesson Mepis Linux learned the hardway after finding there was no upgrade path out of Dapper. However, people who seem to be qualified in handling the scripts on debian, such as the creator of the popular SMXI / SGFXI scripts, seem to have an anti-AMD hard-on or something. The list of people available who want to handle Debian packaging, and are qualified, seems to be extremely small. Again though, that's not really a bug.
Truth be told, AMD/ATi solved most of the big bugs I had in mind. One of the driver sets last year broke Cedega / W.I.N.E. support, an issue that has since been resolved... which is good for my City of Heroes addition.
beecher, I believe both the radeon and radeonhd drivers have tear-free Xv support today. You'll need to pick up drm from either drm- next or the 6xx-7xx git branch of drm, but the X driver code has been merged to master on both radeon and radonhd.
I can't use ati catalyst driver after 8.12
I can't get opengl to work on slackware 12.2
And many slackware users have the same problem with 9.1 and 9.2
I think that not being able to use the driver at all is an greater bug then an minor graphics corruption.
I have a Supermicro C2SEA with the Intel G45/X4500HD, and graphics freezes are common too (about once a day), even without Compiz. Between that and the video tearing, I can't wait for the new graphics subsystem to stabilize.
The 180.xx drivers were a lot faster with KDE4 than the 177s and earlier versions, but it was still a pretty slow experience trying to use KDE4 with my 8600GT. I'm sure KDE4(and/or its dependencies) is partly to blame, but Nvidia's blob surely is also. One eight oh - STILL TOO SLOW. Ultimately, the slight performance increase was not enough to offset the bugs in the 180.xx series - loved that flashing red checkerboard on top of every non-fullscreen video I played. Oh and broken suspend too, that was so awesome.
So I'm back to KDE3 (again, not 100% thanks to Nvidia - but still, in good part), 177.82, and the same old never-gonna-get-fixed, totally-absent-for-no-good-reason TV out overscan control. If that had been fixed in 180.xx I would have put up with the other bugs. It's definitely the bug I hate the most, only it's not a bug so much as it was a decision some fucker at Nvidia made. The new Windows release doesn't need that anymore - so fuck the users of every other OS in existence right?
Does fglrx support running multiple X servers yet? Totally despise that one too.
In summary then, what I hate most is having Windows paradigms forced upon me. I shouldn't be forced to choose between Big Desktop and whatever other mode they offer when X.org offers the ability to run more than one Xserver. The fact that Vista doesn't need overscan controls shouldn't mean that users of every other fucking OS (other Windows versions too!) get the shaft.
There's 10s of millions of Linux users! Isn't that enough to get some fucking respect already?? Sadly I know the answer, and it's no.
What bothers me most is the fglrx driver locking up the whole INtrepid amd64 system (not just X) when I watch a video with compiz enabled. Radeonhd is no solution (yet) either, since the support for my card (a Radeon HD4870) is limited to EXA and Xv. In any case, no useable 3D support yet.
To sum it up: if I forget to switch back to metacity before watching a video, I can reboot my pc.
*Starting to reminisce about the good ol' windows days*
From what I understand, the bug which cause corrupted/not updated graphic is due to a change in Nvidia driver.
Prio to 180.*, the driver used shared memory but not the card memory for pixmap, that cause serious performance problem with 2D graphic (you can test this by scrolling in Firefox). In 180.*, they fixed this by using a cache for Pixmap, but the problem is that when this cache get full, the windows may get corrupted when it was first painted. And this is only happen if compiz is in use, of course.
Aside from the problem with Compiz, nvidia driver work fine with my laptop 8600M card
I don't have any problems with latest nvidia driver nor did with earlier versions, I use Arch Linux with latest vanilla kernel compiled, 8800GT - 9600GT - 260GTX, all run fine . 2D is a bit too slow, it's much better with nouevau. I have tried KDE 4.2 but it's choppy on both nvidia and nouveau drivers, other DE and games run fine.
I tend not to get hung-up on a graphics driver not installing.
Originally Posted by Nille_kungen
Case in point for me is Mepis 7 and Mepis 8. The install script that I had been using up until Catalyst 9.1 suddenly started failing with Catalyst 9.2, and the 64bit install of Fglrx drivers continually failed during the entire Mepis 8 beta series.
However, I would be hard-pressed to refer to an installation problem as an error with the driver itself. Several different factors can affect whether or not a particular driver will run, such as the system architecture (i386 / i586 / i86 / x86-64 / ppc and so on), the kernel version, and the x-server version.
While I think it's useful for driver vendors to be aware of issues with their installers, I think AMD's collaboration with Phoronix (Phorogit) is the right way to go about solving installer issues.
The biggest fly in the ointment, at least on the Debian side, is that Ubuntu has a proven track record of ignore Debian compatibility, and many software vendors seem to get hung up on providing Ubuntu support, rather than simply providing DEBIAN support and making sure Ubuntu stays compatible with Debian.
It's of little surprise to me then that I run into installation problems with Debian (Pure) based distributions when the maintainer of the packages or scripts is working on a deliberate fork.
Now, maybe the Debian problems could be solved if Ubuntu developers focused on maintaining Debian compatibility.
However, I'm not sure bringing what amounts to be political and personal issues into a discussion involving whether or not an installed driver functions as expected in an installed enviroment.
Well if it was an packager bug then it would be ok.
But even when i try to install it without building packages it doesn't work