To be clear, new feature is now better implemented in sgfxi:

Rather than auto running the ia32-libs installer/configurer, now, after seeing if the system A: supports it, and B: is missing it, sgfxi offers you a second option where it said only hit enter to continue, or x+enter to exit, now it offers you, if your system is 64 bit/nvidia driver/missing ia32-libs, a third option, install driver but first add, or attempt to add, ia32-libs.

Since right now that package is broken in sid, it also offers errorhandling and will continue without the ia32 lib install even if it fails.

No user whose system does not support ia32libs multiarch, or that is not 64 bit, or does not use nvidia, will see this option. So in other words, the only time you will see if it is if your system/driver supports ia32libs and is missing it.

The option is: i + <enter>, clearly worded, so there should be no confusion.

This also was an opportunity to update the sort of messy start up options/directions, now they are lined up neatly and more readable.


Back to top

devtalk.nvidia.com/default/topic/628864/unix-graphics-announcements-and-news/num_physpages-and-support-for-3-11-and-later-kernels

sgfxi now has the official nvidia patches for 3.11/3.12 304.108, 319.60, 325 and 331 betas.

All tested and apply, although some have some fuzz / offset stuff, but they all apply.

You might want to reinstall your nvidia drivers if you have installed them with the old patches because these patches are better and more robust.

To reinstall, start sgfxi with -f for force reinstall option.
Back to top

New stable and ltr nvidia drivers: 331.20 / 304.116. These cover 6xxx/7xxx series cards (304.116) and all newer cards (331.20).

Because of the various patching issues, make sure you use these and not older versions.

If you have issues with drivers, please start a new thread on that specific thing so I don't have to split this thread each time.
Back to top

due to various changes and issues in amd fglrx, I've had to make the 13.9 driver get overridden by 13.11 beta6 driver, at this point that is what amd offers as current driver on their website for linux, so that's what I am doing too in sgfxi, that's a hack, hopefully one time, one of an increasingly long string of fglrx hacks sgfxi has to use to keep up with the constantly changing amd groups flounderings.

it's worth observing that the last official stable amd fglrx driver for linux kernels was 13.4, that is, it's been over 6 months since their last official release. Warn your users if you run distros to avoid this card and company if you need non free driver support that works over time.
Back to top

A long time ubuntu/mint bug may now be fixed, it turns out that users were starting sgfxi with sudo, which of course then means that certain events that require root do not get it, including shutting dm down properly.

sgfxi will now refuse to run if you start it with either:

or


but it will allow this:
(note the dash after su) with a startup information message.

If this works, users will be unable to start sgfxi wrong, unless they really really try, which will in turn help solve some long standing issues that only users of ubuntu/mint, or maybe more accurately, users of distros that tell their users to use sudo instead of root to do things, and who also disable the basic root operations for some inexplicable reason.
Back to top

Note to nvidia 5xxx card users, nvidia will be dropping support for the 173 legacy 3 branch as of the last release, 173.14.39

This driver supports xorg 1.15 and I assume kernels 3.12, maybe 3.13, so that means after this release, you'll need to switch to nouveau if you are using a system that runs new xorgs/kernels.

The first 5xxx series card was released in 2003, which means nvidia supported these cards for 10 years, which is amazing when you compare it to amd's pathetic non free support cycle for their cards.

en.wikipedia.org/wiki/GeForce

Consider this reality the next time you are deciding on which gpu to use. For users of free xorg/kms stuff, this doesn't have a huge impact of course, but for users of the non free driver blobs, it's a massive difference, a few years compared to 5 to 10 (5 assuming you bought a close out 5xxx nvidia card in 2007 or so - it's worth noting that I bought a older but new amd / ati card for testing and saw amd drop support literally a month or two later, which made that the last amd card I bought for non free driver user)
Back to top

sgfxi update

Nvidia 6xxxx

Driver 304.117

Kernel 3.12-5.towo-siduction-686

Fine and dandy :-)
Back to top

fglrx 13.12 released, finally. That's 8 months since 13-4 if you exclude the 13.9 that was pulled due to bugs.

As a christmas present, the amd devs gave me NO new path changes, no changes between zip and run file names, no spaces in file names, ie, this one works without fresh sgfxi hacks or issues. I'll take it, given what they've given us the rest of this year, so that's good.

Testing wise, I"m not sure what this supports, I hope/assume xorg 1.15, I assume 3.12, maybe 3.13 kernels,. we'll see.
Back to top

Users report driver module build failure, and apparently, amd forgot to update their installer to patch it, something that was working in the 13.11 beta releases. This company is getting disturbingly sloppy, which strongly hints at poorly controlled outsourced programming and development.

phoronix.com/forums/showthread.php?91885-AMD-Catalyst-13-12-GPU-Driver-For-Linux-Released&p=381943#post381943

sgfxi has added the patch for 3.11 to 3.13 kernels and 13.12 fglrx.

My guess is that amd is going to release a fixed 13.12, they have little choice unless they release 14.1, which will then fix that oversight,, which may then make the patch in sgfxi fail, or the patched file fail, so do watch this and report back.

amd is growing increasingly difficult to support due to their total lack of consistency and quality control, but I'll try to support them a bit longer, unless they do something so incredibly stupid that it will form the actual last straw for me.
Back to top

sgfxi now features theoretically working but not actually tested support for systemd, to go along with its theoretically working upstart and definitely working sysv init system support.

Probably will be bugs because I have no real system, just vm, to test on.
Back to top