It would be useful if you grabbed a couple of register dumps (using this program:[1]. Note that it depends on libpciaccess). The best would be if you got me one from nouveau and another one from the blob, both using the same outputs and same resolutions.

After turning the VGA output on (using xrandr with nouveau or nvidia-settings+twinview with the blob), you just need to type:
# ./tvdump > dump.txt

Thanks.

[1] http://cgit.freedesktop.org/~currojerez/tvdump

Created attachment 34674 [details]
dump after xrandr --output VGA-1 --auto with nouveau

Created attachment 34675 [details]
dump after xrandr --output VGA-1 --off with nouveau

The dumps are only with nouveau as somehow with the recent Xorg the nvidia blob does not work anymore. I will investigate that, maybe I did something wrong or a newer nvidia blob is now available that will work again.

regards
Michael

As it seems for the time being I can't use the blob. I had never an issue with the driver as long as the driver was fine with kernel / xorg versions but this time it puzzles me. Installation went fine, but as I try to start X (gdm) the Nvidia logo shows for a second, then the shell again, then the logo again, then shell and eventually a ncurses message pops up telling me that something went wrong. But NO errors are shown in Xorg log.

So I assume even with the newest nvidia blob (173.14.25) for legacy NV34 chips, a no-go with xorg 1.7.6.

regards
Michael

Created attachment 34912 [details]
dump in singleuser mode

Sorry it took me so long to report back.

As asked on IRC I did run tvdump in singleusermode (no nouveau.ko loaded, no X running). Two things I did notice there:

1.) (I guess directly related) when issued the tvdump command, the screen did not refresh anymore from that point on. I could see the new prompt and type "reboot" (which was shown as I typed it) but the blinking cursor was one line under it and no rebooting (changing runlevel, stopping bla, killing foo, rebooting, ...) messages were printed on the screen, but the box did successfully reboot. To investigate this (if tvdump did cause a segfault or worse) I did start in singleuser mode again, ran tvdump without piping the output to a file, and again no screerefresh, and as ctrl-alt-del did not reboot the box after several 10s of seconds I did power it off (maybe too early...).
Anyway, dump is attached.

2.) (I am almost certain this is another bug and unrelated) As this time was the first time I did reboot the box without playing around with nv vs. nvidia vs. nouveau, in other words a complete "nouveau only session from bootup to shutdown / reboot" I noticed what I have seen before (but before I did play alot with the different graphic drivers so I thought that could happen). It seems the graphic chip was left in a somewhat unclean state. The BIOS messages and grub were utterly damaged and almost completely unreadable (I could glimpse at least half of one kernel line in the grub menu). After a complete powerdown all was well again.
Should I report this as a new bug? At least I did not find an existing bug about a similar issue.

regards
Michael

I see this on x86_64 fedora 14 too.

Hello guys.

We experienced a similar issue with the following card:

0f:00.0 VGA compatible controller: nVidia Corporation G96 [Quadro FX 380] (rev a1) (prog-if 00 [VGA controller])

When we use 2 displays with resolution 1920x1080, then the second screen is always black (led blinking -> off or no signal?) even if xrandr says that both monitors are on. What's strange ... It seems that both desktops are always on the same absolute position (even if we tried to set the position to left-of/right-of/... or by specifying the coordinates)

The same result with combination of 1920x1080 and 1680x1050 ...

When we use 1 display with resolution 1680x1050 and second display with resolution 1280x1024 (via DVI-I to DSUB converter), then dual head works without problems.

Binary drivers can handle all combinations without problems, therefore it doesn't look like a hardware limitation.

Attaching the xrandr output of the working combination:
--------------------------------------------------------
    Screen 0: minimum 320 x 200, current 2960 x 1050, maximum 8192 x 8192
    DVI-I-1 connected 1680x1050+1280+0 (normal left inverted right x axis y axis) 459mm x 296mm
    1680x1050 59.9*+
    1280x1024 75.0 60.0
    1440x900 75.0 59.9
    1280x960 60.0
    1280x800 59.8
    1152x864 75.0
    1280x720 50.0 60.0
    1024x768 75.1 70.1 60.0
    832x624 74.6
    800x600 72.2 75.0 60.3 56.2
    720x576 50.0
    720x480 59.9
    640x480 72.8 75.0 66.7 60.0
    720x400 70.1
    DVI-I-2 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm
    1280x1024 60.0*+ 75.0
    1152x864 75.0
    1024x768 75.1 60.0
    800x600 75.0 60.3
    640x480 75.0 60.0
    720x400 70.1 
--------------------------------------------------------

I'm willing to provide You with any debug information You need.

Created attachment 47681 [details]
tar.gz archive containing tvdump and xrandr outputs for blob and nouveau

The attached file contains the following files:
dump_1920x1080_1280x1024-blob.txt

dump_1920x1080_1280x1024-nouveau.txt

dump_1920x1080_1920x1080-blob.txt

dump_1920x1080_1920x1080-nouveau.txt

xrandr_1920x1080_1280x1024-blob.txt

xrandr_1920x1080_1280x1024-nouveau.txt

xrandr_1920x1080_1920x1080-blob.txt

xrandr_1920x1080_1920x1080-nouveau.txt


In both cases the second display was configured as right-of ...

As it was mentioned before ...
1920x1080_1280x1024 combination works with both drivers correctly
1920x1080_1920x1080 combination works with blob only

(In reply to comment #9)
> Created an attachment (id=47681) [details]
> tar.gz archive containing tvdump and xrandr outputs for blob and nouveau
Thanks for grabbing these.  However.  The chipset you're reporting out has a *completely* redesigned display engine and these dumps aren't useful for it.

Could you please file a separate bug report, as it's highly, highly unlikely that it's related to this one.  Could you attach your dmesg output from while nouveau is running to it also.

Thanks!

No response from the reporter for more than a year. Closing.
If the problem still exists on current version, please reopen with new set of
logs.

Should not have closed this bug
Apologies

Hi,
i use a gentoo distribution and i see that after release of the nouveau kernel driver v. 20110602 (with both kernel 3.x and 2.6.x) dual head doesn't work.
I have a NVIDIA Quadro FX 2800M.

01:00.0 VGA compatible controller: nVidia Corporation G92 [Quadro FX 2800M] (rev a2

So, with version 20110801 and 20110820 there is a regression that doesn't permit correct use of dual head.

Currently, i use xorg-server-1.10.3 (i try soon 1.11.0) but i don't think that problem is on xorg-server.

So,now i downgrade version on kernel module to 20110602 and all works fine.
Please, can you verify where is regression?

As x11 driver i use v. 0.0.16_pre20110323.

Thanks

P.S. If it is needed i will upgrade soon a dump of the xorg.log when dual head doesn't work.

I am experiencing this issue as well with dual DVI outputs.
 - XFX nVidia GeForce 9600GT w/ dual DVI-I outputs
 - dual NEC 2560x1600 monitors
 - xorg-server 1.11.2
 - nouveau 0.0.16_pre20111109
 - Gentoo amd64 linux-3.1.0

xrandr -q reports both monitors as detected and properly configured, and in gnome-shell the desktop appears to extend to the second monitor -- I can drag windows to it -- but the second monitor is always in standby mode.

I can attach any logs/dumps that you need to diagnose this if it would help.

(In reply to comment #14)
> I am experiencing this issue as well with dual DVI outputs.
>  - XFX nVidia GeForce 9600GT w/ dual DVI-I outputs
>  - dual NEC 2560x1600 monitors
>  - xorg-server 1.11.2
>  - nouveau 0.0.16_pre20111109
>  - Gentoo amd64 linux-3.1.0
> 
> xrandr -q reports both monitors as detected and properly configured, and in
> gnome-shell the desktop appears to extend to the second monitor -- I can drag
> windows to it -- but the second monitor is always in standby mode.
> 
> I can attach any logs/dumps that you need to diagnose this if it would help.

Yes, please.  But make it a new bug report, thank you :)

(In reply to comment #15)
> (In reply to comment #14)
> > ...
> > I can attach any logs/dumps that you need to diagnose this if it would help.
> 
> Yes, please.  But make it a new bug report, thank you :)

Bug report made:  https://bugs.freedesktop.org/show_bug.cgi?id=43668

It appears that this bug report has laid dormant for quite a while. Sorry we haven't gotten to it. Since we fix bugs all the time, chances are pretty good that your issue has been fixed with the latest software. Please give it a shot. (Linux kernel 3.10.7, xf86-video-nouveau 1.0.9, mesa 9.1.6, or their git versions.) If upgrading to the latest isn't an option for you, your distro's bugzilla is probably the right destination for your bug report.

In an effort to clean up our bug list, we're pre-emptively closing all bugs that haven't seen updates since 2011. If the original issue remains, please make sure to provide fresh info, see http://nouveau.freedesktop.org/wiki/Bugs/ for what we need to see, and re-open this one.

Thanks,

The Nouveau Team