smxi and sgfxi are now updated to handle the new legacy type, for geforce 8/9xxx and GT 1xx-3xx series cards, plus a few other obscure ones.
Back to top

The reason I wondered if it was a bug was that it correctly selected the right driver on previous kernel updates

Thanks for the update of smxi!


Back to top

"The reason I wondered if it was a bug was that it correctly selected the right driver on previous kernel updates"

This is incorrect, what actually happened was very simple, the legacy 5 branch is 340, and it was only some days ago that 343 became new stable. So as soon as 343 became new stable, and 340 became the legacy 5 series (8/9xxx - GT 1/3xx cards), smxi offered the latest stable, 343, to legacy 5 cards, because smxi did not yet have the legacy 5 logic in place. Now it does, so it correctly assigns the proper driver, as it does with 304 series for legacy 4. The legacy numbers aren't nvidia's, they are internal to sgfxi/smxi, but it makes it easier to handle new legacy cards as they appear.

Someone from siduction some time back alerted me to the new legacy 5 that was coming, but I figured I'd wait until it came to add the support, that's actually easier than trying to do it before.

nvidia, I had forgotten, now has a page that makes it super easy to handle these legacy updates because it lists every single device id for each legacy series.

Note that legacy 3, 173 5xxx cards, are now end of life.
Back to top

Two things :

1. When I try and install the nvidia driver after upgrading to a new kernel, smxi seens to install the driver but desktop fails to start. A re-installation with sgfxi starts fine. Last kernel upgrade I just went to sgfxi and the nvidia driver installed fine first time.

2. There seems to be a need to go to 340.65 after an upgrade to the 3.18 kernel. sgfxi still pulls in 340.58 as the latest kernel for an nvidia series 200 card


Back to top

3I missed the 40.65 update, that is in sgfxi now.

The desktop failing to srart is probably a systemd 'feature' if I had to guess.
Back to top

Thanks for that - 340.65 working fine

Is there any possible reason that it starts after an sgfxi install rather than smxi driver install? I'm fairly sure I had the same issue prior to moving to systemd; this was the first time I just went straight to sgfxi
Back to top

drb, thanks for more data. In theory there should be no difference between a sgfxi desktop start and an smxi desktop start, let me check that code to see if in fact there are subtle differences.

If the sgfxi one is working consistently, I'll use that as the master version, but these should have been the same internally.
Back to top

sgfxi has worked three times in a row with 3.17 and 3.18 and two nvidia drivers (I only tried smxi in two of those cases at it failed both times, hence I went to sgfxi to install)
Back to top

I can't see any actual difference in the logic between smxi and sgfxi x kill/start.

I basically copied the code from one to the other with some small changes because the functions are slightly different, but the core logic appears to be identical.

So my question is, if smxi runs, and you get say a new xorg, then you EXIT smxi, and run sgfxi, does that work?

I've seen issues where it has needed two runs of smxi/sgfxi to get it to work, mepis users have had that issue for ages, I never followed it up because they tend to be painful to do debugging with because of messy changes mepis does to debian.

Now, on the other hand, if you get a new kernel or xorg, and then run sgfxi -k <new kernel> vs running smxi while it has installed a new kernel, and both fail, that's another issue.

These types of tests are very hard, I never see issues myself so I can't reproduce it, once I can, it's easier to fix. But for say, xorg changes, once you've run the install once, you can't count any more data. Same with a new kernel, though there you can install a new kernel, test for this bug, though with new kernel of course you need to use a reboot, so it's hard to see where the failure exactly happened.

the only place smxi really inserts itself into the gfx install process is: start sgfxi with args, and then, after sgfxi exits, start the desktop.

sgfxi alone just starts the desktop, using the same tests and logic, I think anyway, unless I missed something somewhere in the systemd updates.
Back to top

Running smxi twice doesn't work. Running sgfxi only works. Exiting smxi and running sgfxi works.
Back to top