Now not even my old TwinView xorg.conf works any more.
The log files claim that NVIDIA finds the 2nd monitor, but the screen just stays black, even so in TwinView the first screen is stretched out to the right (one more reason why I never liked TwinView is that it keeps stretching my Desktop across two screens, rather than giving me two separate Desktops - ever tried using a toolbar stretched across two screens with very different resolutions?!)

Now here is the output of that infamous "/usr/bin/nvidia-bug-report.sh"
But this time around I will not be waiting a week to be finally told about some secretly hidden "Option" (what's up with all those secrets in Xorg.conf" anyway?).

I'll give this half a day and then I'll be switching driver manufacturers (and I'll be switching card manufacturers next)

PS: That TwinView config which I tried earlier today, worked fine with the old 185.xx driver.
What it did not deliver was a rotated 2nd screen and an independent 2nd Desktop.
That's why I dumped TwinView. But the 2nd Screen was displaying stuff, not just staying black like now :-(

Oh, and I should mention that the fact that your toolbar stretched all the way across your TwinView desktop is most likely a result of the "NoTwinViewXineramaInfo" option you have enabled in xorg.conf. The fact that you cannot rotate an individual monitor in TwinView is indeed a limitation.

As for the ability to switch desktops on the separate screens independently, that's not a limitation of TwinView itself, but the desktop environment. You should see the same limitation with Xinerama.

Oh, and I should mention that the fact that your toolbar stretched all the way across your TwinView desktop is most likely a result of the "NoTwinViewXineramaInfo" option you have enabled in xorg.conf. The fact that you cannot rotate an individual monitor in TwinView is indeed a limitation.

As for the ability to switch desktops on the separate screens independently, that's not a limitation of TwinView itself, but the desktop environment. You should see the same limitation with Xinerama.

I can't switch to the 185.xx driver w/o downgrading my kernel.
I had that one upgraded for new BT functionality (and my BlueTooth works just fine right now), and downgrading it again will mean another night wasted in vain.

Not sure why, but the NVIDIA install script is so messed up, that it won't compile in the new kernel sources no more, because it insist on a file named "kernel.h".

VMware on the other hand is perfectly fine with the good old "version.h and thus compiles on almost anything.

The option "NoTwinViewXineramaInfo" is part of what one of your colleagues told me to specify, last time I spend a week hunting down NVIDIA bugs.
For some reason the NVIDIA driver gets stuck, when trying to do to much probing on the 2nd Display.

Last not least, having two truly independent desktops works just fine with Xinerama. I know because that is what I had been using for the past 6 month.
I get a properly sized and centered toolbar on each screen and I can even setup each screen with its own set of Virtual Desktops.
Its PERFECT and way superior to TwinView.

The rotation on the 2nd Display is *required*, as Lenovo just smacked a standard Laptop LCD on the side of the W700, right side down.
So the 2nd screen is utterly unusable w/o that rotation setting.

Now is there any trick I can use to get the 185 driver to compile with my xx.31.xx kernel?

With this minimal config X is starting up and usable. With the commented option activated the driver will lock the PC including keyboard so that it is impossible to switch to a tty to get the control back. A second PC with ssh is needed (That behavior is described in other posts in this forum). The xorg.log in that situation states as last line:

Code:

NVIDIA(0): Enabling RENDER acceleration

without any EE or WW lines or any more diagnostic lines that could point to a problem.

With this minimal config X is starting up and usable. With the commented option activated the driver will lock the PC including keyboard so that it is impossible to switch to a tty to get the control back. A second PC with ssh is needed (That behavior is described in other posts in this forum).

With this minimal config X is starting up and usable. With the commented option activated the driver will lock the PC including keyboard so that it is impossible to switch to a tty to get the control back. A second PC with ssh is needed (That behavior is described in other posts in this forum). The xorg.log in that situation states as last line:

Code:

NVIDIA(0): Enabling RENDER acceleration

without any EE or WW lines or any more diagnostic lines that could point to a problem.

Thanks for the feedback, but as I can't work with TwinView anyway (see above comment about missing rotation in TW), the prospect of getting my PC locked up on top of that doesn't make it any less unattractive to me.

How come you can confirm that >It does not get all the possible modes as it was before<?!!
Is that a known shortcoming of the new driver and if yes then why the heck would anyone take away mode recognition features in an update?
That's like intentionally crippling features that used to work.

I am no longer interested in that new driver version as it takes wayyy to much time for me to get that stuff2work.
Now I'm just looking for a way to get the old xx.185.xx compiling on my kernel, w/o the "can't find kernel.h..." error message.

Its day #2 after my 2nd screen went black and I tried all the post 185.18.14 drivers up and down the road.
Driver version 185.18.29 actually turns BOTH of my screens black and I only hear a strange hissing noise coming from my motherboard afterwards.

For some bizarre reason version 185.19 refuses to compile yet again on my new kernel, with the same error message as did driver version 185.18.14 (missing "kernel.h").

Last time I checked driver version 185.19 should be higher than 185.18.31 or 185.18.14, so its a mystery to me why they re-introduced the flaw of not being able to handle a more recent kernel :-(
But by now I've come accustomed to NVidia removing features during driver updates, rather than adding them.

So now I've decided to downgrade my kernel back to 2.6.27.xx, so that I can get that NVidia driver 185.18.14 working again.

Which means I won't be able to use those BlueTooth functions anymore, for which I upgraded my kernel in the first place.

3 f*ing days wasted over this!
One thing is for sure, my next $4000+ laptop will not have an NVidia card in it - ATI I'm coming back to you!

I know it's confusing, but 185.19 is actually older than some of those 185.18.* releases.

Since you have the 185.18.14 driver working again, can you please generate the bug report log I requested for comparison against the 190.42 one? I do want to get to the bottom of this problem.

OK, its day #4 and I am finally(!) back were I started (and I sooo much love to run around in circles, 'cause I got nothing better to do all day).

I can now 100% confirm that the last version of the NVidia driver to fully work on the Thinkpad W700ds is indeed 185.18.14.
I find the comment from NVidia that >185.19 is actually older than some of those 185.18.*< not "confusing", but rather silly to be messing around with version numbering like that.

Older versions get lower version numbers than more recent ones - that's how its done!

Now to be 150% sure that this was not an issue of my new 11.2 kernel just not being recent enough for the even more recent NVidia drivers, I actually went all the way to the latest factory kernel release for testing: 2.6.32-1.2.x86_64

Was a pain in the rear to download and install the kernel, sources and compiler by hand, as I don't have the factory repo in my YaST list (for good reasons, as this baby has to be stable above all).

But I did get it to work at last. Hint for anyone trying to attempt the same, if you do get "Can not Build/Load Module" errors after the actual compilation went through just fine, make sure that "/lib/modules/$(uname -r)/build" is linked to a valid directory!
Because that is where the NVidia script insists on dumping its finished modules.
And do not just link that one back to "/lib/modules/$(uname -r)/sources" as I've seen suggested somewhere else, as that will lead to all kinds of crap messages.
If that link is invalid, then you're still missing some kernel source/header package, which you need to install via YaST.

Also, if after (to) much un-installing of NVidia drivers you suddenly get an error msg "can't read libglx.so", then you're not really missing that file, its just that a previous uninstall run of NVidia didn't remove that link. So it still exists, but points to an invalid file name.
Repair that broken link by hand via "unlink <FileLink> && ln -s <RealFile> <FileLink>" and simply run the installer again.
Don't forget to block the FTP download with the (well hidden) option "--no-network", if you got as messed up as I did with the "latest & greatest" from NVidia's FTP archives.

In any case, all that back & forth didn't change a thing. Only after I went all the way back to kernel 2.6.27.29-0.1 and compiler 4.3.4 did I get a usable result. But yet again, only with my original NVidia driver x64-185.18.14.

None of the later x64-185.18.xx drivers worked and the 190.xx, well you know that story already.

I wasted 4 days on this stuff, because NVidia for some reason decided to break a functionality that used to work just fine.
And by the way, these $4000+ Thinkpad W700ds are being sold as officially supported by SuSE & NVidia on Linux.
So yes, I do have kind of an expectation that NVidia keeps up their side of the bargain, at least not take away stuff that used to work just fine already.

Now I got Xinerama back working, with two separate Desktops, with gorgeous native resolutions of 1920x1200 and 1280x1024 and my 2nd Screen tilted left side up - as it should be.