Created attachment 422734 [details] output from "xrandr -q" Description of problem: I suspect the nouveau driver is swapping or mislabeling the two video streams that the NVS-290 card generates. Here are my clues: Setup - Fedora-13 and nouveau driver (latest yum updates as of midnight) - NVIDIA NVS-290 video card - nouveau exposes 2 outputs to XRandR (DVI-I-1 and DVI-I-2) - The NVS-290 video card has a DMS-59 connector, with a short DMS-59 to Dual VGA cable with VGA connectors labeled 1 and 2. - VGA connectors #1 and #2 are connected to monitors #1(Left) and #2(Right). Behavior 1) At boot time, before the nouveau driver is involved, the boot text is output on the VGA connector labeled "1", which is connected to monitor #1 (on my left). 2) At GDM login time, monitor #1 is clearly assigned to the right of the Virtual screen (its right edge is "impenetrable") while monitor #2 is on the left side. Weird, but in theory just an odd default. But wait. 3) Inspecting the "xrandr" output, it is clear that pixels on the virtual screen that are directed to "DVI-I-1" are going to monitor #2 and vice versa (DVI-I-2 goes to monitor #1). I checked the default situation, then flipped the two halves of the virtual screen back and forth with xrandr, checking the xrandr status each time. 4) The last bit of weirdness is that the xrandr geometry setting commands seemed reversed from what would be expected. Maybe that is the inevitable result of mislabeling the data stream, or perhaps it is an important clue in its own right. My head hurts at the point. Misc 5) Oh yes, I buzzed out the cable, just in case it was mis-wired or mis-labled. It's fine, that is DMS59:VGA2_RED -> VGA#2:RED, etc. Version-Release number of selected component (if applicable): xorg-x11-drv-nouveau-0.0.16-6.20100423git13c1043.fc13.x86_64 How reproducible: Always Steps to Reproduce: 1. Boot F13 with NVS-290, dual VGA monitors and nouveau 2. Examine GDM display and monitors 3. Repeat step 2 after logging in with default xrandr settings. Actual results: Left half of virtual screen goes out on DVI-I-2 rather than DVI-I-1, (and vice versa) in both GDM login use case as well as after login. Expected results: Left half of virtual screen goes out on DVI-I-1 and right half goes out on DVI-I-2. Additional info: Obvious one can work around this in various ways, such as xrandr after login (e.g. gnome-display-properties) and/or swapping the monitor cabling. But these are workarounds for a problem and are annoying given that I have both Linux and Windows plugged into each monitor (Linux via VGA, Windows via DVI).
Created attachment 422735 [details] output from "xrandr -q --verbose"
Created attachment 422736 [details] Xorg.0.log
Created attachment 422737 [details] /var/log/messages
My initial thought is: "probably not a bug, we have no way of knowing you've placed a monitor in any particular position" However, can you clarify 4) a bit for me?
Let me try to clarify points 1-3 first -- the "left" half of the 3200x1200 virtual screen, that is pixels with x coordinates between 0 and 1599 are coming out of video card pins for stream #2, even though XRandR says that x coordinates 0-1599 should be mapped to output "DVD-I-1".
Right, I got that much. The *name* DVI-I-1 does in now way mean "the monitor on the far left", we can't possibly *know* you've placed it there.
As to point #4, the confusion I experienced was, upon reflection, of no major significance. In particular, executing "xrandr --output DVI-I-1 --left-of DVI-I-2" does indeed update state so that when doing "xrandr -q" it shows DVI-I-1 as associated with x coordinates 0-1599 and DVI-I-2 as being associated with x coordinates 1600-3199. I.e. DVI-I-1 is to the "virtual left" of DVI-I-2. So that is cool Sadly though, the actual pixels in the virtual range 0-1599 come out over cable #2 (carrying the DMS-59 channel #2 signals) which is NOT what one would expect for the output named DVI-I-1. Similarly the pixels in the virtual range 1600-3199 come out over cable #1 (Carrying the DMS-59 channel #1 signals), even though xrandr says they are going to output "DVI-I-2".
Lastly, yes I know (or at least hope) you can't tell how my monitors are physically arranged. The underlying issue is that there is a mis-match (reversal) between the 2 output names that XRandR displays and the 2 output channels on the DMS-59 connector on the video card. Obvious, that can lead to further confusion as the pixels wend their way to the physical monitors. Let's just focus on the signal on the output connector of the video card.
Hmm, I have a nv4x card with a DMS-59 connector at home. I'm not sure if the connectors are numbered at all but I'll take a look when I'm near it next to confirm something. Basically, nouveau uses information in your BIOS tables to determine what connectors are present etc. In your case we get told about 2 DVI-I connectors (these would map to each of the outputs on the physical DMS-59 connector, but the driver knows nothing about that), and we logically number the first listed in the table DVI-I-1, and the second DVI-I-2. Now, there's another table which lists encoders (VGA, TMDS etc) and what connector they map to. Usually you'll see the table populated with the encoders that map to connectors in order like: VGA-0 -> DVI-I-1 TMDS-0 -> DVI-I-1 VGA-1 -> DVI-I-2 TMDS-1 -> DVI-I-2 However, on your card we see: VGA-0 -> DVI-I-2 TMDS-0 -> DVI-I-2 VGA-1 -> DVI-I-1 TMDS-1 -> DVI-I-1 Now, either your VBIOS manufacturer messed something up, or, nouveau is supposed to create connectors in the order they're mentioned in the encoder table, rather than the connector table. Or it's entirely possible there's some other completely separate way of determining this too. Hard to say without the NVIDIA BIOS specifications :)
Hmmm, interesting and confusing. I presume the BIOS you are referring to is the BIOS on the NVIDIA card. Would the output from lspci be helpful there? Also, For what it's worth. I'm running on a Dell Precision Workstation T3500 with 9GB RAM. Grabbed the NVS-290 video card from a sister T3400 when the NVS-295 proved unusable. Also (YIKES), just noticed all of the HDRD/DMAR errors at the end of /var/log/messages (attached). That doesn't look encouraging. Earlier I had tried to use the NVS-295 (Dual DisplayPort) card that came with my box, but no luck and I noticed it was streaming similar messages albeit at a much faster rate. If there is some useful data gathering I can do regarding either the NVS-290 DRHD/DMAR errors, OR the NVS-295 show-stopping errors, give me a shout and I can plug the old card this weekend.
No that's OK, all the info nouveau uses with regard to that gets displayed in the kernel log anyway :) And yeah, I meant the BIOS on the NVIDIA card. I'm looking over the cards I have with numbered connectors too, and seeing how they map to the various tables in the VBIOS. So far, it looks like we *should* indeed be using the order from the encoder table. But I need to look at more to be as close to sure as I can get without the specs. The DMAR messages etc are fixed in the latest F13 kernels from koji, they were harmless but probably impacting performance a bit due to the log spam. And, NVS295 is known to not work. I'd love to get my hands on one to find out why, remote debugging efforts so far have proven not so useful :)
Created attachment 422753 [details] output of lspci -vvv
Created attachment 422754 [details] output of lspci -xxxx
kernel-2.6.33.6-147.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/kernel-2.6.33.6-147.fc13
kernel-2.6.33.6-147.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kernel-2.6.33.6-147.fc13
Just installed the above kernel and its seems to work fine for me! The output coming out of connector #1 appears to be pixels 0-1599 and connector #2 is 1600-3199. Leaving town in a couple of hours so I haven't had a chance to indulge my obsession with tracing the pixel flow precisely. But I'm sure all will be well (famous last words of course!). Thanks Ben! -- Charlie
kernel-2.6.33.6-147.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.