Bug 10239

(sorry, accidentially hit enter)

Hi!

I have Xserver 1.2.99.901 with xf86-video-i810-1.9.91 installed.  Both outputs on my laptop (builtin screen and attached lcd monitor) are detected fine, but the image on the external monitor (Samsung SyncMaster 171N) has one flickering line (see attached screenshot).  This line seems to duplicate previous lines.  Also the image on the external monitor is vertically a few pixels to large -- I think it is as many pixels to large as the garbled line's width.

Best regards
Christian

Created attachment 9065 [details]
photo of garbled line

Created attachment 9066 [details]
Xorg.0.log

I noticed that I can fix the display by turning the external monitor off and then on -- but the next time I restart X, there's the small garbled line again.

Can you try building the xrandr app, and use it to try the other 1280x1024 modes you have available to you, to see if this issue happens with those?  The hex IDs associate with each that are printed with xrandr --verbose can be used to choose specific modelines.  Alternatively, just construct a modeline for the Monitor-VGA monitor of that CVT mode (Modeline "1280x1024_60.00"  109.00  1280 1368 1496 1712  1024 1027 1034 1063 -hsync +vsync) and put that in the Modes line.

We're suspecting that the monitor is slightly unhappy with the detailed mode it advertises.  If the CVT 60hz mode works instead, we can add a quirk to ignore your detailed mode and pick the other one.

The problem is that I can not perform the test you suggested: The monitor does not display the garbled line if I first start X and then turn the monitor on.  Also, if I switch to another mode and than to the automatically selected mode, the garbled line is not shown.  So the problem does only occur if I first turn the monitor on and then let X start.

Is there a way to instruct the Xserver to switch to a specified mode on start-up?  If this is possible, I could test if the other mode does not cause problems.

$ xrandr --verbose
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 1280 x 1280
VGA connected 1280x1024+0+0 normal (normal left inverted right) 338mm x 270mm
        Identifier: 0x5c
        Timestamp:  -268625002
        Subpixel:   unknown
        Clones:     
        CRTC:       0
        CRTCs:      0
        EDID_DATA:
                00ffffffffffff004c2d6b0037314847
                1a0d01030f221b8cea6f8ba25a4d9424
                1a5156bfef8081806140454031400101
                010101010101302a009851002a403070
                1300520e1100001e000000fd00384c1e
                510e000a202020202020000000fc0053
                796e634d61737465720a2020000000ff
                00484a45573630343939370a202000f4
  1280x1024 (0x5f)  108.0MHz
        h: width  1280 start 1328 end 1440 total 1688 skew    0 clock   64.0KHz
        v: height 1024 start 1025 end 1028 total 1066           clock   60.0Hz
  1280x1024 (0x60)  135.0MHz
        h: width  1280 start 1296 end 1440 total 1688 skew    0 clock   80.0KHz
        v: height 1024 start 1025 end 1028 total 1066           clock   75.0Hz
  1280x1024 (0x61)  109.0MHz
        h: width  1280 start 1368 end 1496 total 1712 skew    0 clock   63.7KHz
        v: height 1024 start 1027 end 1034 total 1063           clock   59.9Hz
[...]

You probably see it in the log, but X.org starts up my external monitor in mode 0x5f.  My monitor's OSD then shows "63,7kHz 60Hz PP 1280x1024".  But my monitor also works with mode 0x61, where it shows "63,9kHz 60Hz NP 1280x1024".

It would like to try starting up my monitor in mode 0x61 to see if the garbled line disappears.  Can you point to the source code file in the driver, which does the mode selection?

Created attachment 9607 [details] [review]
Patch which adds a quirk to work around this bug.

Same as http://lists.freedesktop.org/archives/xorg/2007-April/023594.html

By the way, does the 0x60 mode work?  I think the quirk we might want to create is one that replaces EDID mode timings with the gtf, cvt, or reduced-blanking cvt mode timings for that width, height, and refresh.  That's what you're doing with the ditching of the slightly-higher-refresh 1280x1024x60 mode there, it seems.  If 0x60 works as well, then with this theoretical quirk you'd end up with only CVT 1280x1024@60 and 1280x1024@75 listed (for that size), with @60 preferred, which seems like what you'd want.

(In reply to comment #9)
> By the way, does the 0x60 mode work?

  1280x1024 (0x5f)  108.0MHz
        h: width  1280 start 1328 end 1440 total 1688 skew    0 clock   64.0KHz
        v: height 1024 start 1025 end 1028 total 1066           clock   60.0Hz
  1280x1024 (0x60)  135.0MHz
        h: width  1280 start 1296 end 1440 total 1688 skew    0 clock   80.0KHz
        v: height 1024 start 1025 end 1028 total 1066           clock   75.0Hz
  1280x1024 (0x61)  109.0MHz
        h: width  1280 start 1368 end 1496 total 1712 skew    0 clock   63.7KHz
        v: height 1024 start 1027 end 1034 total 1063           clock   59.9Hz

From this list, only 0x61 works correct, 0x5f produces the garbled line and 0x60  brings up an error message on the LCD's OSD.

eric to look at the patch in comment# 8.

Meanwhile I have upgraded Gnome from 2.16 to 2.18, and in this combination my patch doesn't help. When gdm starts up, the monitors are detected and show a correct picture (without garbled line), but a few seconds after login to Gnome the Samsung monitor turns off and displays "wrong video frequency" instead. Then I have to run the command "xrandr --output VGA --auto", and the image is displayed correctly again.

Maybe there is a program included in Gnome 2.18 that itself tries to detect the monitor settings and which interferes with the Xserver?

That's likely true.  What you really need, it seems, is a quirk to just remove the first two modes from the list, rather than just marking the preferred state on one of them.

a small test patch to see if it helps.

diff --git a/src/i830_display.c b/src/i830_display.c
index 292814c..8a3da1b 100644
--- a/src/i830_display.c
+++ b/src/i830_display.c
@@ -346,10 +346,11 @@ i830FindBestPLL(xf86CrtcPtr crtc, int target, int refclk, intel_clock_t *best_cl
 		    if (!i830PllIsValid(crtc, &clock))
 			continue;
 
-		    this_err = abs(clock.dot - target);
-		    if (this_err < err) {
+		    this_err = clock.dot - target;
+		    if (abs(this_err) < err ||
+			(abs(this_err) == err && this_err > 0)) {
 			*best_clock = clock;
-			err = this_err;
+			err = abs(this_err);
 		    }
 		}
 	    }

(In reply to comment #14)
> a small test patch to see if it helps.

Thanks. I'll test it at the end of next week.

(In reply to comment #15)
> (In reply to comment #14)
> > a small test patch to see if it helps.
> 
> Thanks. I'll test it at the end of next week.
> 

Christian, any update of the test result?

Would you please test the latest driver?

Since we have a fix on the PLL programming issue, now we can find a perfect match for your 0x5f mode. So it's worth a try :)

Thanks,
Hong

Hi!

Sorry for the late reply. I have upgraded to xorg-server 1.3.0.0 and xf86-video-i81 2.1.1, and know I can't reproduce the exact problem. In fact I'm not sure if it's still there. On startup, the monitor is correctly detected and the GDM's log-in screen is shown. After I have entered my user name and password, Gnome starts and any external monitor I have tested shows an "Out of range" message. After that I enter
$ xrandr --output VGA --auto
and the everything is alright again.

Do you know if Gnome 2.18.3 has an own monitor autodetection mechanism which interferes with the driver? I could not find any hint that it is so on the Internet, and also the Gnome preferences do not reveal anything in this direction.

Regards
Christian

Created attachment 12607 [details]
`xrandr --verbose' output after GDM login

This is the output of `xrandr --verbose' after logging in to GDM and starting Gnome 2.18.3. In this state any external monitor I have tested (not just the Samsung SyncMaster 171N) displays an "Out of range" error.

Created attachment 12608 [details]
`xrandr --verbose' output after GDM login and `xrandr --output VGA --auto'

This is the output of `xrandr --verbose' after logging in to GDM, starting Gnome 2.18.3 and running `xrandr --output VGA --auto' from the console. In this state the image on the external monitor is correct.

Created attachment 12609 [details]
Xorg.0.log

Xorg.0.log after logging in to GDM, starting Gnome and running `xrandr --output VGA --auto' from the console.

(In reply to comment #18)
> Do you know if Gnome 2.18.3 has an own monitor autodetection mechanism which
> interferes with the driver? I could not find any hint that it is so on the
> Internet, and also the Gnome preferences do not reveal anything in this
> direction.

I am not sure, it seems that some unknown app has changed the driver to use mode 0x60. And mode 0x5f is OK now.

Can you make sure that your driver has the patch (commid id: 26194e19e1c80615697016e25640d4c8c244353f), we should fix the PLL issue and mode 0x60 should be OK now. I've attached the patch below, you can try it manually since it is a small change.

commit 26194e19e1c80615697016e25640d4c8c244353f
Author: Keith Packard <keithp@koto.keithp.com>
Date:   Tue Nov 13 22:26:40 2007 -0800

    Review PLL spreadsheet and update register ranges.
    
    The PLL spreadsheet makes the precise register ranges allowed for each mode
    quite clear, and shows a few inaccuracies in the b-spec. In particular, the
    N register value may range from 1 to 6 instead of 3 to 8. This should close
    the gap we've seen in the reachable frequencies.

diff --git a/src/i830_display.c b/src/i830_display.c
index d988b86..ea10c8a 100644
--- a/src/i830_display.c
+++ b/src/i830_display.c
@@ -100,14 +100,26 @@ typedef struct {
 #define I9XX_DOT_MAX		 400000
 #define I9XX_VCO_MIN		1400000
 #define I9XX_VCO_MAX		2800000
-#define I9XX_N_MIN		      3
-#define I9XX_N_MAX		      8
+
+/* Haven't found any reason to go this fast, but newer chips support it */
+#define I96X_VCO_MAX		3200000
+
+/*
+ * These values are taken from the broadwater/crestline PLL spreadsheet.
+ * All of the defines here are for the programmed register value, not
+ * the 'counter' value (e.g. Ncounter = Nregister + 2)
+ */
+#define I9XX_N_MIN		      1
+#define I9XX_N_MAX		      6
 #define I9XX_M_MIN		     70
 #define I9XX_M_MAX		    120
+
+/* these two come from the calm1 macro */
 #define I9XX_M1_MIN		     10
-#define I9XX_M1_MAX		     20
+#define I9XX_M1_MAX		     22
 #define I9XX_M2_MIN		      5
 #define I9XX_M2_MAX		      9
+
 #define I9XX_P_SDVO_DAC_MIN	      5
 #define I9XX_P_SDVO_DAC_MAX	     80
 #define I9XX_P_LVDS_MIN		      7

Thanks,
Hong

Hi!

Hong, I've installed xf86-video-intel-2.1.99 plus the PLL patch and I'm happy to say that it fixed my problem. The Samsung SyncMaster 171N does not display "Out of range" anymore after login to Gnome.

Thanks!
Christian

Created attachment 12717 [details]
`xrandr --verbose' output after GDM login

This is what `xrandr --verbose' now looks like after login to Gnome.