Description of problem: I'm attempting to get two monitors to function in a "standard" LeftOf (or RightOf, however you please) configuration using nouveau and a GTX 260. The first monitor, identified as DVI-I-0, works properly at its native resolution (1680x1050). The second monitor, identified as DVI-I-1, does not. Whenever -1 is enabled in any fashion, the monitor displays a partial mirror of -0, with a weird green overlay. Attached is a picture of this... oddity. I've tried configuring -1 with xorg.conf, xrandr, krandrtray, KDE4's Display settings, and Gnome's display settings. The results are the same on all of them. Version-Release number of selected component (if applicable): -xorg-x11-drv-nouveau-0.0.12-36.20090514git9656762.fc11.x86_64 -Linux desktop.averageurl.com 2.6.29.4-167.fc11.x86_64 #1 SMP Wed May 27 17:27:08 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux How reproducible: Always Steps to Reproduce: 1. (Assuming the second monitor is disabled) Enable the second monitor with any xrandr-type tool. 2. Observe the broken. Actual results: See attached photo. Expected results: I should be able to drag a window from one to the other. Additional info: Attached is my lspci, xorg.conf, Xorg.0.log, and example picture.
Created attachment 347143 [details] xorg log
Created attachment 347144 [details] lspci
Created attachment 347145 [details] xorg conf
Created attachment 347146 [details] picture of working monitor
Created attachment 347147 [details] picture of second (broke) monitor
Just some notes from working with Kyle on IRC so I don't forget: - booting with just the "bad" display connected works - VBIOS comes up on "good" display by default - kms and nv have the same problem - seems that non VBIOS-assisted outputs fail on this card too - enabling BIOS output script execution in kms mode fixes the problem. Won't be able to enable nouveau.uscript=1 by default for a while yet, too little testing, and known broken cases.
Created attachment 347155 [details] xorg log w/ kms
Created attachment 347156 [details] dmesg w/ drm.debug=1 uscript=1, init 3
Hey, are you able to update to the kernel build from http://koji.fedoraproject.org/koji/buildinfo?buildID=112059 and ensure that the uscript code still works as expected for you? There have been some significant changes to the code in that build.
No, it does not work as expected. One monitor simply stays off. That monitor, incidentally, is the one with the kdm login box. I'll be attaching a drm.debug=1 dmesg log + Xorg.0.log.
Okay, after rebooting back into -191, the second monitor still came up dead. Shut it off for a moment, booted into windows, both displays worked fine. Rebooted back into -191 and.. second monitor still dead. Log files being attached now..
Created attachment 349835 [details] dmesg w/ drm.debug=1, kernel -201
Created attachment 349837 [details] Xorg.0.log with -201
Created attachment 349844 [details] wrong sized loading screen After swapping which DVI port the monitors are attached to, the larger monitor (which wasn't coming on) came alive just fine. The smaller monitor - which was working - didn't. Further, the loading screen came up on the 1680x1050 monitor, but only rendered at 1440x900 (see attached picture - ignore the coloring, that's just a bad camera with lots of glare. The colors are correct). This is on -191 after booting -201.
Dropping back to -167 (f11 stock release) resulted in a desktop that works.
Created attachment 350014 [details] dmesg w/ drm.debug=1, kernel -205, working I noticed -205 with a nouveau change - so I grabbed the source, tweaked the .config to give me a bigger dmesg log, rebuilt, installed, enabled drm.debug and... ... it worked great. Running said tweaked -205 now with no issues. Attached is the full (non-truncated!) dmesg.
Excellent, good to hear! The info that -191 also didn't work was a good indication that there was yet more fallout from a DRM change that got pushed into F11 recently :)
Ok, I'll close this as fixed in rawhide. Though you have tweaks to make it work now, it should JustWork(tm) out of the box in F12.