Bug 16148

i have reported this bug to FC9.
https://bugzilla.redhat.com/show_bug.cgi?id=446626

This issue is reproducible when using the latest driver from git repo.

Created attachment 16808 [details]
screen

When dual head is enabled with randr12 option, primary display is borked, and secondary display is borked if dvi connector is used.

Created attachment 16809 [details]
text console

The text console appears kindda blurry, as if viewing a text screen on a telly.

Hi, still interested in fixing this? If so:
* can you check the problem is still present on the latest version in git?
* am I correct to understand that when RandR12 is enabled, the laptop display is incorrect, even without having the external DVI screen plugged in? Also, by running with `Option "Randr12" "off"' in xorg.conf and starting from a fresh boot, the problem is not present?
* assuming the problem can be reproduced using only the laptop screen, is the display still broken on returning to VT (either by Ctrl+Alt+F(n) or by closing X)?

> * can you check the problem is still present on the latest version in git?
Will do. the h/w should be available with me by coming monday

> * am I correct to understand that when RandR12 is enabled, the laptop display
> is incorrect, even without having the external DVI screen plugged in? Also, by
Yes

> running with `Option "Randr12" "off"' in xorg.conf and starting from a fresh
> boot, the problem is not present?
Yes

> assuming the problem can be reproduced using only the laptop screen, is the
> display still broken on returning to VT (either by Ctrl+Alt+F(n) or by closing
> X)?
Yes. If i restart X after disabling RandR12, i end with with a "telly" like screen ( horizontal rolling strips )

-- ritz

Assuming it doesn't work with updated software, can you also try:

1) starting from a non-corrupted state, start nouveau with nv_bios.c:call_lvds_script patched out:

--- a/src/nv_bios.c
+++ b/src/nv_bios.c
@@ -2965,6 +2965,7 @@ void call_lvds_script(ScrnInfoPtr pScrn, struct dcb_entry *dcbent, int head, enu
        uint32_t sel_clk_binding;
        static int last_invoc = 0;

+       return;
        if (last_invoc == (script << 1 | head) || !lvds_ver)
                return;

and check whether the picture in X is ok, and whether the picture on returning to console is ok.

2) Make register dumps while in X, and attach them here -- one with randr12 disabled (and no corruption present), and one with randr12 enabled and the corruption present -- as follows:

git clone git://people.freedesktop.org/~stuart/radeontool
make
./radeontool regs > logfile

> 1) starting from a non-corrupted state, start nouveau with
> nv_bios.c:call_lvds_script patched out:
> --- a/src/nv_bios.c
> +++ b/src/nv_bios.c
> ...
> and check whether the picture in X is ok, and whether the picture on returning
> to console is ok.

Nope. All i see is blank black screen. Switching to console and back to X, i end up with a image of console ( translucent) on X. 

The console works fine.

> 2) Make register dumps while in X, and attach them here -- one with randr12
attached.

-- ritz

Created attachment 18639 [details]
logs

(In reply to comment #7)
> > 1) starting from a non-corrupted state, start nouveau with
> > nv_bios.c:call_lvds_script patched out:
> > --- a/src/nv_bios.c
> > +++ b/src/nv_bios.c
> > ...
> > and check whether the picture in X is ok, and whether the picture on returning
> > to console is ok.
> 
> Nope. All i see is blank black screen. Switching to console and back to X, i
> end up with a image of console ( translucent) on X. 

Hmm, a blank screen is surprising :-) As regards this translucent console, I don't understand -- how is it different to the normal console display? what indication is there that you are in X and not still at the console?

> The console works fine.

I assume by this you mean that the console is fine after leaving X; correct me if I misunderstood.

> > 2) Make register dumps while in X, and attach them here -- one with randr12
> attached.

There seems to be a problem here -- all four of the nouveau dumps appear to be made from the console, rather than from within X. If you were doing them blind, is it possible that X had crashed? If you were doing them from the console while X was running in order to see, could you instead leave the computer *in X* and run the dump commands from another computer over ssh?

Please close this bug, as I do not have access to the hardware in question. 

-- ritz

(In reply to comment #10)
> Please close this bug, as I do not have access to the hardware in question.