Created attachment 14886 [details]
Xorg.log of the X session with connection of the monitor

I've noticed a problem, but this is beyond a quick fix, so this may take a day or two.

It seems it went a little faster than expected, please retry with current git.

Created attachment 14906 [details]
newer xrandr --verbose output with git head

(In reply to comment #4)
> Created an attachment (id=14906) [details]
> newer xrandr --verbose output with git head 
> 

Hmm, nothing has changed in regard to this bug, I still get the same behavior. I'm attaching again the xrandr --verbose output and the xserver log.

Created attachment 14907 [details]
Newer xorg.log

There is another potential issue, but i'll have to ask someone else about it.

Some ideas of things to test:
1) Is the situation any better if the external head is plugged at boot?

2) If nouveau does not bring up the lvds head, does the external head work? -- to test this, add "return XF86OutputStatusDisconnected;" to the top of nv_lvds_output_detect in nv_output.c

3) Attaching the output of "radeontool regs" to the bug (when both heads are plugged and nouveau is running) would be interesting.

4) Likewise, comparison reg dumps if suggestions 1) or 2) work would be invaluable.

(In reply to comment #8)
> Some ideas of things to test:
> 1) Is the situation any better if the external head is plugged at boot?
> 

This is funny: it is reversed like this

xxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxx
oooooooooooooooo
oooooooooooooooo
oooooooooooooooo
oooooooooooooooo

meaning the top third or so is black, while the rest is ok, in full width this time.


> 2) If nouveau does not bring up the lvds head, does the external head work? --
> to test this, add "return XF86OutputStatusDisconnected;" to the top of
> nv_lvds_output_detect in nv_output.c

This does not change anything with respect to attaching the second head while X is running: the left stays black

> 3) Attaching the output of "radeontool regs" to the bug (when both heads are
> plugged and nouveau is running) would be interesting.
> 
> 4) Likewise, comparison reg dumps if suggestions 1) or 2) work would be
> invaluable.
> 

I'm attaching reg dumps in the two different situations, plus the xorg log with the second head plugged at boot

Created attachment 14909 [details]
regdump with second head connected at boot

Created attachment 14910 [details]
regdump with second head hotplugged while X is running

Created attachment 14911 [details]
Xorg.log with second head connected at boot

Created attachment 14912 [details]
xrandr --verbose output with second head connected at boot

Created attachment 14913 [details]
Xorg.log with second head connected at boot

Is the external head a real CRT, or instead an LCD over an analogue connection?

For the situation where the top of the screen is missing (plugged at boot), what happens if you start nouveau -- does the top half stay missing, or does it change to the side being missing? Does this change if you disable the laptop display as described previously, and have the external head plugged in before starting X?

If when nouveau is running and the screen was plugged at boot the external display is any different to how it looks when hotplugged, a register dump would also be useful -- I'm guessing the previous one was done from just offb?

(In reply to comment #15)
> Is the external head a real CRT, or instead an LCD over an analogue connection?
> 

This time it was a real CRT, the previous tests were with an LCD over analogue

> For the situation where the top of the screen is missing (plugged at boot),
> what happens if you start nouveau -- does the top half stay missing, or does it
> change to the side being missing? Does this change if you disable the laptop
> display as described previously, and have the external head plugged in before
> starting X?
> 

Well, at boot the external became all white with flickering when the kernel got loaded and then when X started it came up displaying the bottom two thirds with the top one black. I then tried unplugging, replugging, restarting X with the monitor unplugged, etc. but the behavior remained this, it never reverted to the situation "left third off" that happens when the external head is not plugged at boot but hotplugged during a X session. In order to see again the "left off" behavior I had to reboot keeping the monitor unplugged.

Disabling the laptop display does not change anything: if the monitor is connected at boot the top is off when X starts, if instead (after a reboot) I connect it before starting X the left stays off.

So I would say that the difference in behavior is given by having the monitor connected at boot time. There's no difference instead between connecting it before X starts or with X running.

> If when nouveau is running and the screen was plugged at boot the external
> display is any different to how it looks when hotplugged, a register dump would
> also be useful -- I'm guessing the previous one was done from just offb?
> 

No, both regdumps were done with the external head connected and working under nouveau, the first one is when the external head was connected at boot (and so top missing), the second one when it was simply hotplugged during a X session (left missing). I didn't make myself clear on this.

So, the analog isn't activated properly by offb?

Also, can you test the dvi?

(In reply to comment #17)
> So, the analog isn't activated properly by offb?
> 
It is not. The same seems to happen during osx bootup: the analog remains white and flickering until the graphical login screen appears

> Also, can you test the dvi?
> 

I don't have a DVI cable at hand, I'll see if I can get one in the next days

There has been a regression in the last two or so weeks: the secondary head is still missing the left third and furthermore the image is flickering, like a wrong frequency is set. Comparing a regdump with a previous one the culprit is found to be the value of NV_RAMDAC_SEL_CLK0: the driver recently sets the wrong value of
 0x00040014, whereas the old one was 0x00040044. Setting it manually with radeontool fixes the flickering, but of course the left third stays black.

I did not manage to test dvi output, but I was however able to obtain a regdump from OSX in the same configuration, i.e. secondary head connected and working in mirror mode. I used airlied's hacked osx radeontool to do so, I'm attaching the file in case you might find some source of inspiration in it

Created attachment 15557 [details]
Regdump of osx in mirror mode

Please attach an xorg log where sel_clk setting is misbehaving.

Created attachment 15564 [details]
Xorg log with misbehaving SEL_CLK

Here it is

SEL_CLK should be fixed now

(In reply to comment #23)
> SEL_CLK should be fixed now
> 

Yes, I can confirm this. The original issue is sill there though. Hopefully in the coming weeks I'll have more time to dig into this issue and dump the dumpable on OSX.

Btw, nice job fixing the backlight-that-didn't-turn-off problem :)

Coming back to this bug after a long time... The issue is still there with VGA. I was able to test also the DVI output and that works perfectly :)

As a sidenote I'd like to point out that the PB12 has just a single mini-dvi output, that gets used both by dvi-out and vga-out with two different adapter cables. Don't know if this could be somehow related though

Hi, looking at the regdumps again, the programmed monitor sizes are very different; it's possible this is related to what's going wrong, but it seems more likely the osx and linux radeontool dumps were made with different monitors attached or had the same monitor running in different resolutions - do you happen to recall if this was the case?  If it was, would you be able to make new comparative dumps, of the same monitor (attempting) to run at the same resolution (perhaps check in the xorg log for what res nouveau is setting, then do the same in osx?).

The other issue is that there's something odd with the linux-made radeontool dumps, causing the CRTC reads to be mis-indexed by one, such that the value of CR(n) is printed in position CR(n+1).  Can you check please that there's no modifications to your copy of radeontool before making any new dumps?  (or clone a clean copy from git://anongit.freedesktop.org/~stuart/radeontool )

Jacopo, how is it going with respect to this bug?
Could you try with KMS and see what the current situation is?

I believe I'm seeing the same bug here on my 12" 1.5GHz PowerBook. I installed Nouveau from git yesterday, and attaching my LCD monitor via VGA and enabling via xrandr results in 20-30% of the left side of the screen coming up black. Attaching via DVI works perfectly.

Looks like I have KMS enabled:
$ sudo cat /sys/module/nouveau/parameters/modeset
1

So I guess that doesn't help any. Let me know if there's anything I can provide that could help this along. Sadly I don't have access to OSX at the moment though.

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