Bug 16148

Summary: primary display is borked with RandR12 enabled
Product: xorg Reporter: Ritesh Khadgaray <khadgaray>
Component: Driver/nouveauAssignee: Nouveau Project <nouveau>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg log
none
screen
none
text console
none
logs none

Description Ritesh Khadgaray 2008-05-29 05:22:22 UTC
Created attachment 16807 [details]
Xorg log

Primary (laptop's) display is borked, when RandR12 option is enabled. Additionally, when using DVI conector the secondary display also starts acting weird ( rainbow coloured checkboxes).

Version-Release number of selected component (if applicable):
kernel-2.6.25-14.fc9.i686
xorg-x11-drv-nouveau-0.0.10-2.20080408git0991281.fc9.i386

How reproducible:
always

Steps to Reproduce:
1. Enable RandR12 option
2. Enable dual-head using gnome-display-properties
3. Display goes crazy
  
Actual results:
Crazy psychedelic coloured display

Expected results:
Sane boring functional display

Additional info:
xorg log attached
Comment 1 Ritesh Khadgaray 2008-05-29 05:23:14 UTC
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.
Comment 2 Ritesh Khadgaray 2008-05-29 05:39:56 UTC
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.
Comment 3 Ritesh Khadgaray 2008-05-29 05:40:59 UTC
Created attachment 16809 [details]
text console

The text console appears kindda blurry, as if viewing a text screen on a telly.
Comment 4 Stuart Bennett 2008-08-17 10:29:02 UTC
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)?
Comment 5 Ritesh Khadgaray 2008-08-18 02:24:43 UTC
> * 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
Comment 6 Stuart Bennett 2008-08-18 07:26:24 UTC
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
Comment 7 Ritesh Khadgaray 2008-09-02 06:09:37 UTC
> 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
Comment 8 Ritesh Khadgaray 2008-09-02 06:11:18 UTC
Created attachment 18639 [details]
logs
Comment 9 Stuart Bennett 2008-09-14 10:25:21 UTC
(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?
Comment 10 Ritesh Khadgaray 2009-02-05 10:49:17 UTC
Please close this bug, as I do not have access to the hardware in question. 

-- ritz
Comment 11 Marcin Slusarz 2010-07-23 16:42:32 UTC
(In reply to comment #10)
> Please close this bug, as I do not have access to the hardware in question.

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.