Bug 14403

Oh, I forgot to add:  If I try to switch modes on the LVDS-0 using 'xrandr -s ..', nothing changes...  (Still black)

When I return to text mode, things are a shade of green, but I can't actually see the cursor. (As if things were shifted or something...)  

Please provide a full log with NOUVEAU_MODESET_TRACE in nv_local.h enabled.

A full log includes a VT switch or shutdown.

A comparison log with randr12 disabled would be nice too.

Created attachment 14177 [details]
randr 1.2 log with debugging turned on

Created attachment 14178 [details]
Defualt log with debugging turned on

Alright, both are attached.  If you need anything else, just ask.

Does the LVDS work on it's own?

No, I don't think it does. (I tried it once, and then I plugged in the other monitor so I could actually interact with the laptop.) 

However, let me just reconfirm that, and submit new logs (rand1.2 and without) without any external monitor attached.  

(Unfortunately, It'll have to wait until tonight.) 

Created attachment 14187 [details]
Non-randr startup using only the laptop screen

Created attachment 14188 [details]
randr1.2 Xorg.0.log using only the laptop screen

Ok. Both of these logs were taken in single user mode after a fresh boot.

Oh, and as I suspected, the laptop screen still doesn't work (even when the other monitor is not plugged in.)

So, I don't know if this is relevant, but I was looking at the log files, and it
seems like the pitch and virtual size is screwed up (or at least different) in the randr dump.

I'm going to try to hard code a Virtual size of 1680x1050, and see if anything changes.

no randr:
(--) NOUVEAU(0): Virtual size is 1680x1050 (pitch 1680)
(**) NOUVEAU(0): *Driver mode "1680x1050": 119.0 MHz, 64.7 kHz, 59.9 Hz
(II) NOUVEAU(0): Modeline "1680x1050"  119.00  1680 1728 1760 1840  1050 1053 1059 1080 +hsync -vsync

....

Randr:
....
(--) NOUVEAU(0): Virtual size is 1680x1680 (pitch 1728)
(**) NOUVEAU(0):  Driver mode "1680x1050": 119.1 MHz (scaled from 0.0 MHz), 64.7 kHz, 59.9 Hz
(II) NOUVEAU(0): Modeline "1680x1050"  119.12  1680 1728 1760 1840  1050 1052 1058 1080 -hsync -vsync
....

Hi,

Just to be certain, can you confirm that the external screen works correctly when using randr1.2?
You say the laptop screen is blank - does it appear to be off (no backlight), or  black, but still on and backlit?

In reply to #10: the pitch is normal, it is different because you want to rotate.

Other comments: this issue *seems* to be similar to the one with 12" powerbooks (NV34): with rand12, panel does not work. But externally attached (analog) displays work fine. To me it seems related to the fact that I see that here and in my logs, the BIOS tells us we are on CRTC 1. This is slightly strange maybe, but I do not see why it shouldn't work. Of course, I may be wrong and this can be a different issue.


danny

i can confirm this issue, at least that the screen stays black; i haven't tested an external display yet. this is on powerbook g4 17", geforce4 440 go 32m.

Reply to #11.

Yes, the external monitor works just fine with randr1.2.  I can change resolutions , and that works, too. 

The laptop screen is on (backlit) but nothing appears on the screen. 

Also (possibly related), the switch back to text mode fails to. I see text that is tinted green, but I don't see my cursor, and when I type nothing appears to change on the screen. 

(once again, I DO see text on the external monitor, and am able to type...) 

The greenish text/garbage is a sign that the color mode is not correctly set. Probably indicating a larger problem.

Please can you:
git clone git://people.freedesktop.org/~airlied/radeontool
git checkout origin/nvidia

then attach to this bug the output of "radeontool regs" when running nouveau both in randr12 and non-randr12 modes, when you have booted *without* the external head attached (doing it remotely is fine, since obviously in the randr12 case you're blind)

Ok. I got radeon tool + the nvidia branch.  It was detecting my nvidia bridge instead of the graphics card.

I had to hard code the base address to 0xe2000000 (the graphic card's MMIO control register address.) 

I'm pretty sure this is right:

01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 440 Go 64M] (rev a3) (prog-if 00 [VGA controller])
        Subsystem: Hewlett-Packard Company Unknown device 006d
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 22
        Memory at e2000000 (32-bit, non-prefetchable) [size=16M]
        Memory at f0000000 (32-bit, prefetchable) [size=128M]
        Memory at f8000000 (32-bit, prefetchable) [size=512K]
        [virtual] Expansion ROM at f8080000 [disabled] [size=128K]
        Capabilities: [60] Power Management version 2
        Capabilities: [44] AGP version 2.0
        Kernel driver in use: nouveau
        Kernel modules: rivafb, nvidiafb

Anyway.  The reg files for the randr12 and non-randr files are soon to be attached.  The are both taken after a reboot with NO external monitor connected. 

Created attachment 14300 [details]
Radeon tool dump of nvidia registers: NO randr 1.2, single head (no external monitor)

Oh, and my latest test are on nouveau head of line.

Created attachment 14301 [details]
Radeon tool dump of nvidia registers: randr 1.2, single head (no external monitor)

Ok, from looking at a quick diff of those, NV_RAMDAC_FP_CONTROL1, NV_RAMDAC_FP_DEBUG00, and NV_RAMDAC_OUTPUT* stand out as possibly interesting.

Respectively, can you try these:
1) nv_crtc.c:1494
        change regp->fp_control[nv_crtc->head] = 0x00000000;
        for regp->fp_control[nv_crtc->head] = 0x00100000;
2) nv_crtc.c:1696-7
        remove the two lines with PWRDOWN in them
3) nv_output.c:601-2
        swap output_reg[0] for output_reg[1], and vice-versa

One other thing (very unlikely to have an effect) is to avoid the ORing of pllsel with NV_RAMDAC_PLL_SELECT_VCLK_RATIO_DB2, nv_crtc.c around line 790

Just to be absolutely sure about what you are asking me to do.

Do you want me to try
#1 
(back out #1) #2
(back out #2) #3

Or do you want me to try:
#1
#1+#2
#1+#2+#3

Either way, I'll take a swing at it tonight. 

Created attachment 14334 [details]
Register dump after all three fixes have been added to head of line

I tried the patches individually (1, 2, 3), and also 1+2, 1+2+3. 

None of them changed things.

I've attached a register dump with ALL three applied.  I haven't had a chance to
try the other PLL thing that you suggested.

Working from the all three applied state of your last dump, the diff against no-randr12 shows a few things still, so (on top of the previous changes):
0) do the PLL_SELECT change (unlikely to do anything, but still)
1) nv_crtc.c:1454 regp->fp_vert_regs[REG_DISP_CRTC] = 0x41a;
2) nv_bios.c:2808 
if (pNv->dcb_table.entry[dcb_entry].type == OUTPUT_LVDS)
        (i.e. remove dual_link test)
 & nv_crtc.c:1533 remove "if" test so 
regp->fp_control[nv_crtc->head] |= (8 << 28) is always set
3) nv_bios.c:3152 lvdsmanufacturerindex = 1;

Success!

If I set the following, 
"3) nv_bios.c:3152 lvdsmanufacturerindex = 1;"

I am able to boot up into X.  I can then use xrandr to switch between resolutions. 

In fact, that patch is the ONLY one necessary.  I removed all of the others, and it still works. 

There are still some bugs (for example, my console is messed up when I return to X), and also a few resolutions (for example 1024x768) are completely corrupted.

However, I figure I'll wait to report those until you have an 'official' patch now that we know what the problem is. 

A fix for this has been committed. Does it work for you with latest git?

d.

Yes.  I tried with head as of a day or two ago, and it works now.