[Xorg-1.7.5 in Slackware64 -current] still no workie.. Xorg bug?
 

UPDATE -- July 27 2010

I'm pleased to be able to say that this issue now appears to be resolved. I never got things to work with the versions of drivers & software that this thread is about, but over the 3 months that have passed since I created this thread, it appears that with the latest nVidia driver, and the currently current version of Xorg in Slackware64, the problem has been fixed. Maybe I'll never know what exactly the problem was, but no matter - all is working well now as I type this.

Please see post #91 of thread for currently working versions of Xorg & driver I am using.

Thanks to everyone who provided input & tried to help! I appreciate all of it.

Older update:

UPDATE -- I no longer think kernel .config has much if anything to do with this, so I changed the thread title. It seems to be an Xorg bug, based on info provided by folks in this thread, and by continuing to search the net for info.. So, I no longer request kernel .config files.

I am still trying to figure out why I cannot install and run Xorg-1.7.5 in Slackware-64-current. Soon, I'll hafta say $#%$ it and blacklist Xorg, and stay at 1.6.3 forever.

I believe I've tried pretty much everything..

-- I've used multiple different kernels from 2.6.32.x and 2.6.33 (no RC kernels).
-- I've tried the nvidia driver, the nv driver, and the vesa driver.
-- I've pruned down my xorg.conf to a rather simple version.
-- I've disabled Xinerama, disabled TwinView, disabled my second screen.
-- I've tried 2 or three different nvidia drivers.
-- I've checked and re-checked for missing components, libraries, corrupt packages.
-- I've recompiled my kernel a half-dozen times.
-- I've disabled my wallpaper-setting (fbsetbg) in my WM.
-- I've rebuilt my WM a half dozen times; rebuilt the WM's dependencies; rebuilt the WM again!

I've posted to nvidia's forum; nobody seems to have a clue, and have not had any replies to my thread.. I'm not entirely sure the problem even has anything specifically to do with nvidia anyhow -- as mentioned, I DID clean all proprietary nvidia code from my system and try the vesa driver too, and the `nv` driver also, and these didn't work either.
I also searched their forum for issues relating to the Xorg-1.7.5 but came up pretty empty; same with Google.

I've gone through my generated nvidia-bug-reports myself; of what I do understand from them (quite a bit) indicates no problems. What I do NOT understand from them, well, that's just it -- I don't know what to look for with register dumps and this sort of crap.

Still, I cannot install Xorg-1.7.5 and run `startx` without hanging and/or crashing my machine. It simply does not work.

RIGHT NOW: I am running the Xorg-1.6.3 at this very moment (from Slack64-13) along with the xf86-mouse and xf64-keyboard modules which came with that Xorg-1.6.3, and everything is peachy-perfect. But with ALL OTHER THINGS staying the same, if I upgrade my Xorg to 1.7.5, it no longer works.

I know that pretty much everyone else around here, who has upgraded to -current, is evidently running the new Xorg-1.7.5 without significant issue.

The only thing I can figure to try next, is alter my kernel configuration (again -- yes, I've done this already a few times). I have been using nearly identical kernel configs for the last year or better; I migrate my .config to my next kernel version, check for new/missing features, basic sanity check, and rebuild. No problem. Till now (and maybe it's not the kernel either..)


So, if you fit the following criteria, please email me your /proc/config.gz file, I'd like to diff it against mine.:

1-- you're running -current-64
2-- kernel 2.6.32.8 or 2.6.33 (I'll take very close relatives of these too!)
3-- you have two (or even one) nvidia cards running.
4-- you have one display per card, using Xinerama.
5-- you use nvidia-190.53 driver successfully.

Even if you're kinda similar to the above, I'd be interested in looking at your kernel config. Preferably the kernel versions should be close, the nvidia driver should be the exact same, and ideally ( important ) you should be running two+ displays by some means.

And please -- don't tell me I should buy ATI hardware, or try to sell me dual-head-2-go -- I'm happy with the hardware I have (usually).
If you DO have any suggestions I should try that I may not yet have done, feel free -- I'm listening.

Thanks people.

Sasha

I don't think it's the kernel config, however, here is mine, but it might not be very useful for you, since it's not for 64 bit kernel and it's also patched with zenkernel.

http://linvo.org/devel/config

Some questions:
1. Have you tried this on a normal -current without 64 bit support?
2. Have you tried to pre-compile X.org, maybe without HAL support?

You can try with this package, xorg-server 1.7.5.901 which is using udev for auto-configuration instead of HAL: http://linvo.org/repository/linvo-20...901-i686-2.tgz
Remove xorg-server before installing it.
However, it requires all the X packages a usual xorg-server requires from slackware-current (and NOT slackware-13.0), and also all the other updated things from current. Make sure everything is updated, all the series! That may also be the reason why the current thing doesn't work. Also, with the new udev and 2.6.33 kernel, make sure CONFIG_SYSFS_DEPRECATED is disabled, else NOTHING will work!

If the behavior is really the same with the vesa drivers, just try everything on a clean -current with the original slackware kernel. Create a new partition, let's say 6GB, and use installpkg (not the official slackware installer) to install all the series except kde and kdei to a new slackware-current installation. Make sure you have installed the xap/ series, however, since you need some kind of WM, or X will crash! That's a very important thing! It can also be the reason why X doesn't work for you. Try starting kdm or some kind of display manager before doing anything!
http://www.linuxquestions.org/questi...e-13.0-764400/

I'm just running the stock vmlinuz-generic-2.6.33 kernel + modules (note: not a monolithic/'huge' based one).

Blacklisting the nouveau module seems vital to getting anything working for me.

The 'nv' driver just doesn't work at all, no matter what I do.
The 'vesa' driver works fine.
The proprietary 'nvidia' 190.53 driver works fine once you put the nvidia-190.53-2.6.33.patch.txt patch on it

This is just a single card/single display system though, so I don't know how much value this will be to you.

Apperently you are not the only person having problems with Xinerama and Xorg-1.7.5. Note the update comment of March 9 in the link below.
http://zuttobenkyou.wordpress.com/20...al-head-setup/

Like GazL, I am running the stock vmlinuz-generic-2.6.33 kernel + modules, with nouveau blacklisted and the patched 190.53 driver on both 32 bit and 64 bit.
I use separate X screens driven by the one GPU to drive my two monitors. which is working fine for me, but is different from your setup.

Thanks you guys -- I'll keep you's posted as to what happens with all this, but probably not much until tonight at the very least -- I've been up all night already so might sleep a lot today :)

@ Ivshti -- I followed the LQ link you gave, and some of the OTHER links from those links, and find this stuff about "need a display manager, or install KDE" to be distressing. It implies that a WM alone will not be enough (is this right?) which is counter to the exact reason I now use just a nice little WM started from init3/startx and do not have KDE installed.
Sheesh.
-- I have not tried a 32bit -current; there should be enough 32bit users around to figure out those problems ;)
-- I haven't *yet* tried to recompile Xorg, but it IS on the menu for soon. And yes, HAL will be out of it.
-- I *am* using a WM, but not from /xap -- I'm using a non-slack WM called i3: http://i3.zekjur.net/ but I do have ALL of -current installed including the xap tree. Only at this moment of course I have downgraded Xorg, mouse, and kbd packages.
-- I won't install all KDE junk just to try KDM, so I'll see if XDM works instead.


@ GazL - me too, the nv driver does nothing at all for me, never has; it just won't work. But normally (with one screen anyhow) I can use the VESA driver to test stuff, but currently (ha ha) even that doesn't work.
I'm using a patches 190.53 nvidia driver, which installs fine, and works great with Xorg-1.6.3 and any kernel I choose, but not with Xorg-1.7.5. I do have nouveau blacklisted too, even though I haven't ever seen any sign of it being 'around' on my machine.

Many thanks for the tips & help -- updates later!

Sasha

@ allend - thanks, your post popped up when I posted.

The OP at that link you gave, uses an xorg.conf nearly identical to my own; uses nvidia; and has two monitors the same size as mine. Great comparison!

I will read all the comments, I haven't yet. But I did note that just before the comments, he said he uses Arch, and because the new Xorgs barf at his config file, he's continuing to use Xorg-1.6.3, the same as I am right now, because it STILL WORKS :)

lol :scratch:
more reading to do. Thanks again!
Sasha

Nope, not KDE. You just need to make sure that startx starts X with _SOMETHING_, else X found itself in a "idle" situation (got nothing to do) and collapsed.

Since startx might be confusing sometimes, and may not start your WM and you may not understand that this is happening, installing a display manager and running it is the best way to find is your X working.

I know this is weird - but as I said, X needs something to run in it since Slackware 13.0, or crashes.

@ Ivshti -- if I'm not mistaken, KDM is part of KDE, is it not? (I just checked, it does look that way) Which if so, requires installing *some* of KDE to get it.. I'm just going by what I read in one of the threads linked to the one you linked above.

My WM is started from my /etc/X11/xinit/xinitrc file, the same way some other WM or DE are started by that means, and it DOES start. It's just that within 10 seconds or so (or sometimes it waits till I press something or use the mouse) it all freezes up. Most of the time I have to then use Magic SysRq to sync/umount/reboot, but once in a while I can get back to a VT if I'm lucky.

If it's only freezing when you do something like move the mouse/hit a key, then is it possible that it's something to do with input handling, and all that hal hot-plugging nonsense?

have you tried doing it all the old way instead, which is what I do.

xorg.conf extract:

Yes, but KDM isn't the only login manager out there ;)

Anyway, that's really bad. I guess it's HAL. Try using my package, or even easier, the method GazL suggested.

Which WM?

There is a bug in current releases of Xorg with Fluxbox, and other *box WM's (not OpenBox). Also disabling HAL (AllowEmpty "False") has been reported as causing issues with Xfce <-- Though I believe that one to be more of a config issue personally ;)

http://cgit.freedesktop.org/xorg/xse...dfb0637c20559a

What is your Xorg setup?

My last upgrade of -current 64 have the same problem of Shinobu comment on link posted. My cursor is unstable on second screen.

I have second Monitor on VGA output of my Notebook working fine before last Xorg update of -current.

I have patched NVidia driver 190.53 with only nouveau blacklisted.

My xorg.conf:

I'm wondering if xinerama is the culprit here. I'm running the latest -current64 with the generic 2.6.33 kernel and the unpatch 190.53 nvidia driver. As others have stated, I had to blacklist nouveau (couldn't even boot without blacklisting it).

Does your setup work without xinerama and on just one screen?

To address a few recent posts above (now that I'm awake from a nap)

Yes, I've had it "doing it the old way" ever since Slack13 and HAL came along. I have those 3 magic entries in my xorg.conf. Thing is, depending on what other stuff I have commented out (or not) in xorg.conf, the freezing happens even without any input events -- I just run `startx` and sit there and watch without touching anything, and within a few seconds, I see my status-bar clock stop 'clocking', and that's it -- frozen hard.
At the other times (I've changed xorg.conf so many times I'm not sure now which precisely are the options which affect this) it appears to not freeze until I touch the mouse, and then it locks up hard.
yes ;) I know, I was just making the point that it would be painful to install a whack of KDE just to use KDM to start X successfully. I mean to try SLIM one of these days, just haven't yet gotten around to it. Hopefully if I *NEED* to use a DM, that will suffice. If not, then XDM will do as well.

[off-topic] -- I installed some of the newer KDE packages so I could use KWrite a bit today, and got reminded again of why I got rid of KDE -- frikkin working on something and all the sudden *POOF* "Sorry the application encountered an error and had to close...". Ahhh memories coming back from the old MS days :/
[/off-topic]

Which WM? I am using i3 ( http://i3.zekjur.net/ ) which is inspired (but not based on) DWM. Maybe it's similar to the *box WM's but I'm not really sure.
I'll take a look at that FD.org later on and see what it has to say.


@ rmjohnso above post -- Nope, with the Xorg-1.7.5 my setup does not work even with only one monitor/screen enabled. No matter what I tried to adjust or change in xorg.conf, (I did not try physically removing card#2 from the machine, and am not about to) it would not work. It's like \(my system\) with \(Xorg-1.7.5\) is like trying to mix \(pure spring water\) and \(motor oil\) :) -- simply doesn't work.

Thanks for the continued input!

For the record, here's my xorg.conf (I'm perfectly running this very config as we speak, comments and all, with Xorg-1.6.3):

Sounds quite similar to this entire conversation to me
http://www.mail-archive.com/arch-gen.../msg11775.html

Hmm, yes, it does look VERY similar, and from what I gather from reading that convo, HAL is not directly part of the problem, but rather, it appears to be an Xorg bug. Thanks for that link. I have yet to follow the one or two off-shoot links from it.

This evening, I'll hopefully make time to try some other Xorg-1.7.5 packages such as linked above in this thread by another member, and see if it helps.

But with any luck, *IF* it is an Xorg bug and it gets "fixed" soon, then -current will get a new Xorg package soon after, so if I don't manage to try some of the patched Xorgs that are flying around, I'll definitely be looking forward to a new package in Slack-current.

Thanks again,
Sasha

Caveat emptor: I am running Slackware64-13, not current and didn't try 2.6.33 nor Xorg7.5 (yet) and don't use HAL (I have reconfigured xorg-server-1.6.3 with the '--disable-hal-config" option) BUT...
... I am very happy with the nouveau driver so ...
... Sasha, may I suggest you give it a try ?

- Follow this http://nouveau.freedesktop.org/wiki/InstallNouveau
- Skip only step 2 as the nouveau kernel driver is included in the 2.6.33 tree
- Blacklist nouveau
- But load it at end of startup (I suggest adding /sbin/modprobe/nouveau at the end of /etc/rc.d/rc.local)

Of course follow all installation steps at runlevel 3

Please let us now the outcome.

PS I'm gonna try -current to see what I get ASAP - but I need to make some room for it on my hard disk first...

Didier,

yes, I have no problems about getting off of 'the blob' so nouveau is already on my radar. I don't play 3D games or design space-shuttles, or simulate earthquakes :) so nouveau may do all I need from a video driver-- provided it can use either Xinerama or XrandR to make both my displays work. Thank you for the link and supplemental instructions there, I am going to check it out soon.

At the risk of stating/asking the obvious though: using nouveau (or not) has no bearing on whether or not Xorg-1.7.5 works for me, does it? I mean, if the VESA driver doesn't work for me, chances are good that nouveau won't help.

However either way, to try nouveau, I'll be needing to rebuild my current (not "-current") kernel to enable the nouveau DRM, so I'll look into this shortly for the heck of it.

Sasha

Sasha, can you post your xorg log?

Matt

@ Matt -- which version of the log would you like? One from a failed X session using Xorg-1.7.5? Or the current log from my session I am running right now?

There seems to be a gentoo guy who has xorg 1.7.5 running with nvidia with a patch
http://forums.gentoo.org/viewtopic-p...831cc76250a138

@ReinaldoNS - The difference between your xorg.conf and mine is that I have Xinerama disabled:\

OK, well reports are becoming a little more easy to locate, about at least one bug in Xorg which is leading to a lot of folks using small WM's having very similar problems to what I am experiencing.

I think for the time being, I'm going to just not upgrade my Xorg-server package until there's convincing evidence that this *is* a bug and that it has been fixed.

# Didier -- I am just now back from a couple hours spent trying out nouveau. I see it has potential for sure, but...
To make the long story short: the results were about the same as I currently get using Xorg-1.7.5 with any other driver, except that it was harder to actually get the server started because it kept erroring out with something like (EE) Unable to open device once for each card. I tried at least 10 different xorg.conf files, ranging from none at all, to the minimal one given as an example on the nouveau wiki page you linked for me, and ranging up to the full xorg.conf I am currently usung. Most of the time, X would not start, giving the above error. After un-blacklisting nouveau and rebooting (it would not work if I modprobed nouveau after bootup) I managed to eventually get X to start ONCE, and ONCE only -- it activated ONE screen, with no mouse or keyboard support working, and then promptly locked up. I rebooted using Magic SysRq.

So... I've had about enough frigging with Xorg for a day or two :) and will take a break from this until I find some convincing evidence that there's a new package or something to try upgrading to. It *really* looks like an Xorg bug.

I'm very sure I have some other projects to fiddle with here!

Thank you to everyone who had some input here -- I am not done with all your suggestions, but again, need a little break.

Sasha

Sasha,

I am sorry nouveau + Xorg7.5 didn't work.

I added a new partition to my hard-disk to run -current, I will install it later today and try Xorg7.5.

<off topic>After modifying my hard disk's layout I couldn't boot... Hopefully ( start Slackware DVD && mount root Slackware partition on /tmp && chroot /tmp && nano /etc/fstab && nano /etc/lilo.conf && lilo ) worked.</off topic>

Take care,

No worries Didier :) it was worth a try; and, I'm happy that nouveau is working for some people, and continues to improve. Thanks for the idea; unfortunately (and I kinda suspected as much) it did not work for me.

I changed the title of this thread, and edited the first post, to better reflect what I've learned so far from everyone's feedback, i.e. that it probably is not my kernel, but it appears to be an Xorg bug (that's now my stance ;) ).

Best of luck trying out your -current install! We just got a batch of new packages again a few hours ago :) -- do let us know how it goes -- if you need help, you don't hafta look far!

Sasha

Would you mind please posting the link for this driver!
 

I'd like to know where to find this. I've already searched the net and haven't found it. You can try this yourself to see that nothing comes up:
search terms (nvidia-190.53-2.6.33.patch index-of)
NADA!!

Xavian-Anderson Macpherson
Shingoshi

Here is what I did and got with slackware64-current as of yesterday:

1) Installed the huge kernel
I got a black screen shortly after booting, may be because nouveau was loaded at boot time (it's modularized even in config-huge-2.6.33) but I missed the nouveau firmware, which is requested at time module is loaded if using 2.6.33 (see chapter 3 here about that)

2) Installed the generic kernel + initrd + blacklist nouveau.
I could boot to runlevel 3 but after startx (under Fluxbox) I saw only the mouse cursor on a black screen. I could move it... that's it. Hopefully Ctrl+alt+del sent me back to runlevel 3.

3) Installed libdrm with support for nouveau + xf86-video-nouveau + the firmware for nouveau. "modprobe nouveau" worked but "startx" failed with this (quoted from Xorg.0.log)
4) Just in case, re-compiled xorg-server with --disable-config-hal, killed the HAL daemon, re-used my /etc/X11/xorg.conf from slackware64-13 which works with nouveau. Alas, got the same result.

So I will stick to -stable and xorg-server 1.6.3 for now.

Meanwhile I will try the 2.6.33 kernel on it in order to help narrowing the origin of the problem.

PS In a former post I forgot to mention the necessity of firmware installation and also that libdrm should be installed in /usr/lib64 for Slackware64-current, that is to say using following command to configure libdrm :
And of course you can skip step 1 as well as step 2 in this document provided that xorg7.5 be already installed.

And in fact it's not necessary to load the nouveau kernel module at all, as if its name is included in xorg.conf, X will load it when it (hopefully) starts.

Sorry about missing information, which by the way I included in this other thread some time ago.

Best regards,

HERE IS THE PATCH HFILE i DON'T REMEMBER WHERE i GOT IT ORIGINALLY

JOHN

Sasha, can you post the Xorg log from the failed 1.7.5 start?

I just double-checked my settings, and I'm running Xorg 1.7.5 with nvidia-190.53 (patched to install against kernel 2.6.33). I'm on a laptop, so I don't use xinerama.

Here is my xorg.conf file, for what it's worth:

Oops...
 

Sorry, (at least a part of) the solution to my problem (see former post) was written black on white here http://nouveau.freedesktop.org/wiki/...oopendevice.22 :
As a punishment, I'll upgrade nouveau drm code and report the outcome ;)

LOL :)

Good morning everyone!

@ Didier -- I had already figured out the stuff you mentioned in post #27 (that you had omitted earlier -- no biggie!) about the --libdir=/usr/lib64 and I also had had the firmware installed in the right places, even though I **thought** I understood from the nouveau wiki that if we are building a fresh nouveau with the drm kernel, then the external firmware is not required. I might have that last part wrong*** (*** see below)

HOWEVER: I did not come across what you last wrote above, about the drm code 2.4.18 AND from git not being compatible with nouveau (kinda silly in my book..).

*** Seems that although the nouveau wiki is "pretty good", it isn't great, and as we see, it's easy to miss some key information. Maybe you could write up a decent How-To for Slackware/Slackware64 on how to install nouveau? Of course, it may well get lost in the mix of this thread, so a new thread would be a good place. And, if you come up with a step-by-step that works for you, and you would like me to test it out before posting it, let me know.

Either way, do let us know how your latest adjustments affect the outcome, for your -current system. I'm perhaps up for another round of testing today.. Perhaps..

@ rmjohnso -- I believe I have a log or two here from a failed Xorg-1.7.5 startup.. Yes, I do... Here's one that I attached to my thread in the nvidia user forums (the entire logs are nearly identical to those produced when I am running Xorg-1.6.3 successfully, except for a few lines tacked onto the end, like so, highlighted in bold):

I'm running current-32bit and I also had stabilityproblems with xorg-1.7.5 -- the system just froze.
I tried different kernels, differnet nvidia-drivers... At the end of this trial-and-error procedure (I didnt't tried nouveau or nv though) my system magically worked again.

Today I recompiled my kernel and the nvidia-drivers and the problem was there again. During the third bootup or so I glimpsed a message concerning nvidia-driver 195.36, although I had 195.30 installed.
The last line of my crash-xorg.log reads
I installed 195.36 and the sytem is now stable for almost 2 hours.
Hope you can solve your problem.

Best wishes
m.

Dear G-TransGirl ;)

I've had a similar problem with latest Xorg. Also running Slackware64 with nvidia card and xserver did crashed with sigsegv short after startup. Caused by old hal configuration files hanging in /et/hal/fdi/policy. Try to clean this subdir and restart hal. Make sure hald is really running before launching of xinit. Even if automatical adding of devices from HAL is disabled in xorg.conf .
My config with disabled KMS and binary nVidia drivers ver. 190.53 works just perfect. I've some weakness for tiling wm too but currently using wmii so I cann't report about ion3.

I'd also warn to use latest beta drivers. See nvidia news for more details.

Sasha, short of doing a reinstall, the only thing left I can think of is to check your hal policies like dunric suggests.


Matt

Okie dokey, well HALd is definitely running -- it shows me all its threads in HTOP indicating which drives I have disabled polling for (about 8 of them, or IOW, *all* of my drives and card slots).

As for crappy stale files in /etc/hal/fdi/policy I'm not sure what would define "crappy stale" files differently from "current, good" files.. Maybe if I just wipe the directory and remove & reinstall HAL (cursed thing..).

also, @ dunric - my WM is i3, not ion3. Different entirely: http://i3.zekjur.net/

Thanks you guys -- I'll havva look at the HAL policies, although as mentioned above, there are some mailing list threads coming about now wherein a few other people are experiencing similar weird lockups with the latest Xorg's, and in some cases, patching Xorg has worked for them. Anyhow, I'm not going to play with patches, I'll wait till the thing gets fixed, if it is indeed broken. Off I go to look at Hal :/

Sasha

Oh, and PS - I'm a member on nvnews forums so have been following the announcements and stuff over there about the latest drivers. Can't generally get any help over there, but it's good for reading about other people's problems, and checking on driver updates :)

Dear Sasha,

eventually I got nouveau working on slackware64-current with xorg-server-1.7.5 and kernel-generic-2.6.33.

The How-To is appended, would you like to try it?

Thank you in advance.

PS I didn't use HAL, but I suppose it *should* work with it. Let's see...

Best regards,

[EDIT] Step 6 some drivers to erase are in subdirectories, sorry about that -- anyway "find" will tell you.

I will try it, yes, now that there's a one-piece tutorial :)

Thanks. Maybe this evening I'll give it s try. Whenever it is, I will be sure to let you know how that goes.
Currently I am still using HAL (like, it is still installed and allowed to function, barely) but when I get around to it (I say that a lot) I will recompile Xorg without it. Hal = Freaking nuisance for folks who don't need it, BUT: I'm not complaining about it, I understand we need *something* for people using the big DE's, so please nobody jump on me for whining about HAL :p 'cause I'm not.

Thanks Didier, I'll update later.

Same here after updating by slackpg-upgradeall! :(

I converted this to a script...
 

I've edited this How-To into a bash script. Look it over and tell me if it's still correct. I substituted the "Ctrl + d" with "exit" instead. I believe that's what's required within a shell script.

Xavian-Anderson Macpherson
Shingoshi

Oh, sorry. Close names but different tiling WM with quite different distributions licenses - respectable vs. insane ;)

Hope you'll find the way out soon.

Not sure I understand that last line you wrote there :) about finding my way out. I can't even find an actual LICENSE page for Ion WM (and I'm not going to download it just to see), but from what I gather from wikipedia, it's some sort of LGPL-based thing.

The i3 WM appears to be GPL'd though not explicit in which version; but, since I'm not distributing it, and it's open-source, it's all good IMO.

Hello Sasha,

I got X working on a stock slackware64-current install with kernel-generic-2.6.33:
- blacklist nouveau
- setup an xorg.conf file with driver "vesa" (may be it suffice to rename the xorg.conf-vesa as xord.conf)

I tried nv as well. X started but the screen was ugly with weird color, with Fluxbox as well as in XFCE. I didn't bother to install KDE so I didn't try with it

I will post that on another thread along with the Nouveau_How-To

FYI I have a Quadro NVS 140m GPU on my Thinkpad T61.

Cool :) thanks for the continued feedback Didier.

I'm getting some breakfast now and have some household junk to deal with, but later on today I may find the time to test this out again! Link your new Nouveau-How-To to this thread if you would :)

Thanks,
Sasha

you do realize when upgrading to current the entry in /etc/modprobe.d/blacklist.conf blacklist nvidiafb so blacklist nouveau and #comment blacklist nvidiafb get it running and recompile that kernel do like I did leave neavou out of the build. I use the patched 195.30 beta works great on kde 4.4 also.
as far as addressing the multi screen and client issue sorry down to one monitor.
Like you could not compile anything even the xorg. I found on my first up grade the mirror did not have the kernel-header pkg then later there it was drove me crazy.
went to another mirror and got it.

But does nouveau work with Xinerama? Or is it just Xorg 7.5 that does not work with Xinerama?
Considering Sasha has pretty much narrowed it down to a bug with Xinerama in Xorg 7.5.

FWIW, using Xinerama, I've experienced some odd effects with Xorg 7.5 as well. Single monitor's and twinview all work superbly. Just recently decided to try Xinerama since my configuration was 100% stable, I needed something to break so I could fix it ;)

For the record -- even WITHOUT Xinerama enabled, Xorg-1.7.5 still does not work for me. I cannot get 1.7.5 to work properly AT ALL.

I do think it's an Xorg problem, since I have tried eliminating *most* other possible contributing factors, AND since other folks around the net (as seen in some external links linked in this thread) are experiencing similar issues.

One thing I have NOT tried (and in all honesty, I believe this should NOT be relevant) is a stock Slackware kernel. I've been building my own kernel for close to 3 years, so as far as I'm concerned, if my kernel suddenly doesn't work with Xorg version YYY but it works with version XXX, that's an Xorg problem. Besides, there are Arch and Gentoo users having similar troubles.

@ Drakeo -- I really don't understand all of what you wrote in your last post there, about the "compiling" and about the blacklist file. Could you perhaps re-write that post, to clarify it a bit? :)

Sasha

lol @ disturbed1 -- and did Xinerama work for you?

Umm, sort of ;) X did not crash, it was stable - but the mouse/touchpad does not properly relate all events to all programs all the time. Quite annoying. I used Xinerama for ~20 minutes in each desktop (Fluxbox, Xfce, KDE) clicking this or that, moving stuff around - no crashes, no glitches - just the random mouse thing. Twinview and single monitor work as expected.

To be honest, at this point I'd have to say it is your configuration that is causing the problem, since even without Xinerama you still can't get things to work. Something had to change between Xorg versions to make your old working configuration not work anymore.

Here, 3 systems with Nvida drivers and Xorg 7.5 everything is working fine. 1 system with 2.6.33, others still using 2.6.32.8. Nvidia GT220, 9400GT, and NVS140m. I've only tried multiple monitors with the laptop (NVS140M). Every system uses HAL. More or less, the following is my entire xorg.conf

And, disturbed1-- forgive me, I'm not quite sure from your above post: in your multiple-monitor configurations, are the different monitors connected to DIFFERENT cards, or THE SAME card? (PS - (EDIT) if the multi-monitor stuff was on your laptop, I assume a single card then, yes?)

As for my configuration, I tried a LOAD of different configurations, down to and including NO config file at all, and also tried a very minimal one very much like the one you show above. Still no go.

Same card, I only included that since you were having problems even with a single card/single monitor.


Not knocking your config - just stating a fact that Xorg changed something. Considering everything is peachy-keen with the last release :)

--------
Have you tried other WM's? Forgive me if you already posted this, can't remember.
And did you rebuild your WM against all of the updated libs?