Bug 14859 - External analog monitor does not show part of the output (Randr12)
Summary: External analog monitor does not show part of the output (Randr12)
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: PowerPC Linux (All)
: medium minor
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-06 11:56 UTC by Jacopo
Modified: 2013-08-18 18:10 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xrandr --verbose output (with monitor connected and working) (4.16 KB, text/plain)
2008-03-06 11:56 UTC, Jacopo
no flags Details
Xorg.log of the X session with connection of the monitor (93.04 KB, text/plain)
2008-03-06 11:58 UTC, Jacopo
no flags Details
newer xrandr --verbose output with git head (4.16 KB, text/plain)
2008-03-07 04:55 UTC, Jacopo
no flags Details
Newer xorg.log (85.06 KB, application/octet-stream)
2008-03-07 04:58 UTC, Jacopo
no flags Details
regdump with second head connected at boot (8.66 KB, text/plain)
2008-03-07 08:48 UTC, Jacopo
no flags Details
regdump with second head hotplugged while X is running (8.66 KB, text/plain)
2008-03-07 08:49 UTC, Jacopo
no flags Details
Xorg.log with second head connected at boot (5.73 KB, text/plain)
2008-03-07 08:50 UTC, Jacopo
no flags Details
xrandr --verbose output with second head connected at boot (5.73 KB, text/plain)
2008-03-07 08:50 UTC, Jacopo
no flags Details
Xorg.log with second head connected at boot (93.89 KB, text/plain)
2008-03-07 08:52 UTC, Jacopo
no flags Details
Regdump of osx in mirror mode (12.20 KB, application/octet-stream)
2008-03-29 06:27 UTC, Jacopo
no flags Details
Xorg log with misbehaving SEL_CLK (84.05 KB, application/octet-stream)
2008-03-29 11:18 UTC, Jacopo
no flags Details

Description Jacopo 2008-03-06 11:56:11 UTC
Created attachment 14885 [details]
xrandr --verbose output (with monitor connected and working)

Whenever I plug an external analog (VGA) monitor to my 12 inches Apple powerbook I can see with xrandr that it is correctly recognized. When I turn it on with xrandr --auto my desktop appears on the external monitor (mirroring) in full height (768), but on the left the first 290 or so pixels out of 1024 are black and the same happens to the last 16 on the right. This same behavior happens with two different monitors.
Image quality is excellent and there's no distortion or stretching whatsoever, the pixels are just plainly black. To give an ascii-art idea:

xxxxxooooooooooox
xxxxxooooooooooox
xxxxxooooooooooox
xxxxxooooooooooox
xxxxxooooooooooox
xxxxxooooooooooox

x are black, o are ok (proportions are of course not respected :))

Trying to change the resolution doesn't give a different behavior. I'm attaching a xorg.log and the output of xrandr --verbose

This happens with git head for both ddx and drm, xorg server 1.4.1~git20080131-1 (debian package) and libxrandr2 1.2.2-1 on debian lenny ppc
Comment 1 Jacopo 2008-03-06 11:58:06 UTC
Created attachment 14886 [details]
Xorg.log of the X session with connection of the monitor
Comment 2 Maarten Maathuis 2008-03-06 12:57:44 UTC
I've noticed a problem, but this is beyond a quick fix, so this may take a day or two.
Comment 3 Maarten Maathuis 2008-03-06 14:10:20 UTC
It seems it went a little faster than expected, please retry with current git.
Comment 4 Jacopo 2008-03-07 04:55:47 UTC
Created attachment 14906 [details]
newer xrandr --verbose output with git head
Comment 5 Jacopo 2008-03-07 04:57:39 UTC
(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.
Comment 6 Jacopo 2008-03-07 04:58:52 UTC
Created attachment 14907 [details]
Newer xorg.log
Comment 7 Maarten Maathuis 2008-03-07 05:19:58 UTC
There is another potential issue, but i'll have to ask someone else about it.
Comment 8 Stuart Bennett 2008-03-07 07:01:01 UTC
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.
Comment 9 Jacopo 2008-03-07 08:47:56 UTC
(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
Comment 10 Jacopo 2008-03-07 08:48:52 UTC
Created attachment 14909 [details]
regdump with second head connected at boot
Comment 11 Jacopo 2008-03-07 08:49:29 UTC
Created attachment 14910 [details]
regdump with second head hotplugged while X is running
Comment 12 Jacopo 2008-03-07 08:50:15 UTC
Created attachment 14911 [details]
Xorg.log with second head connected at boot
Comment 13 Jacopo 2008-03-07 08:50:46 UTC
Created attachment 14912 [details]
xrandr --verbose output with second head connected at boot
Comment 14 Jacopo 2008-03-07 08:52:33 UTC
Created attachment 14913 [details]
Xorg.log with second head connected at boot
Comment 15 Stuart Bennett 2008-03-07 11:48:13 UTC
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?
Comment 16 Jacopo 2008-03-08 04:29:54 UTC
(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.
Comment 17 Maarten Maathuis 2008-03-08 04:59:21 UTC
So, the analog isn't activated properly by offb?

Also, can you test the dvi?
Comment 18 Jacopo 2008-03-08 05:31:28 UTC
(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
Comment 19 Jacopo 2008-03-29 06:24:38 UTC
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
Comment 20 Jacopo 2008-03-29 06:27:14 UTC
Created attachment 15557 [details]
Regdump of osx in mirror mode
Comment 21 Stuart Bennett 2008-03-29 07:35:55 UTC
Please attach an xorg log where sel_clk setting is misbehaving.
Comment 22 Jacopo 2008-03-29 11:18:21 UTC
Created attachment 15564 [details]
Xorg log with misbehaving SEL_CLK

Here it is
Comment 23 Stuart Bennett 2008-03-29 14:15:32 UTC
SEL_CLK should be fixed now
Comment 24 Jacopo 2008-04-02 14:59:08 UTC
(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 :)
Comment 25 Jacopo 2009-02-06 01:58:40 UTC
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
Comment 26 Stuart Bennett 2009-02-07 16:12:44 UTC
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 )
Comment 27 Pekka Paalanen 2009-11-19 13:33:39 UTC
Jacopo, how is it going with respect to this bug?
Could you try with KMS and see what the current situation is?
Comment 28 chckens 2010-03-03 04:56:47 UTC
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.
Comment 29 Ilia Mirkin 2013-08-18 18:10:39 UTC
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


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.