Bug 23833

Created attachment 29371 [details]
Xorg.0.log

Created attachment 30224 [details]
Xorg log when booting with "nomodeset"

Any news on this? I am attaching Xorg log and xrandr --verbose output using 2.6.32-rc3 and intel 2.9.0.

Created attachment 30225 [details]
Xorg log when booting with default kms

Created attachment 30226 [details]
xrandr --verbose when booting with "nomodeset"

Created attachment 30227 [details]
xrandr --verbose with default kms

(In reply to comment #5)
> Created an attachment (id=30227) [details]
> xrandr --verbose with default kms
Does the system still work well although the different refresh rate is used in X and console mode?

From the log it seems that the 1280x1024@75Hz standard mode is removed by x-server as the pixel clock is beyond the range obtained from EDID.
  >The pixel clock of 1280x1024@75Hz is 135MHz. But the max pixel clock from EDID is 130MHz. (Ranges: V min: 56 V max: 75 Hz, H min: 31 H max: 80 kHz, PixClock max 130 MHz)

In the console mode the 1280x1024@75Hz is not removed as the max pixel clock in EDID is not used to validate the given display modeline.

Thanks.
> 

> Does the system still work well although the different refresh rate is used in
> X and console mode?

Yes.

> From the log it seems that the 1280x1024@75Hz standard mode is removed by
> x-server as the pixel clock is beyond the range obtained from EDID.
>   >The pixel clock of 1280x1024@75Hz is 135MHz. But the max pixel clock from
> EDID is 130MHz. (Ranges: V min: 56 V max: 75 Hz, H min: 31 H max: 80 kHz,
> PixClock max 130 MHz)
> 
> In the console mode the 1280x1024@75Hz is not removed as the max pixel clock in
> EDID is not used to validate the given display modeline.

So it is a kernel bug. I am available to test any patch if needed.

Thanks

Just to remind this is still not fixed on 2.6.32 final.

This one should be fixed in 2.6.35-rc kernels; I think we'll pick 60Hz on TFTs now.

I am using 2.6.35 final but this is still not fixed.

The discrepancy appears to be due to:

drivers/gpu/drm/drm_edid.c:
static u32
range_pixel_clock(struct edid *edid, u8 *t)
{
        /* unspecified */
        if (t[9] == 0 || t[9] == 255)
                return 0;

        /* 1.4 with CVT support gives us real precision, yay */
        if (edid->revision >= 4 && t[10] == 0x04)
                return (t[9] * 10000) - ((t[12] >> 2) * 250);

        /* 1.3 is pathetic, so fuzz up a bit */
        return t[9] * 10000 + 5001;
}

The addition of 5MHz for the non-CVT EDID is just enough make the 135MHz pixel clock mode valid given the 130MHz max. The X EDID parser has no fuzz and so removes the detailed mode.

I wonder what is the best approach here? Fix X to interpret the EDID the same as the kernel, fix the drivers to trust the modes supplied by the kernel, or something else?

Adam Jackson pointed out that X should be doing a similar fixup, but sadly fails because at the point it does so, it doesn't have all the information to hand...

commit fc2ec95664d55f45f77f1ebb039a7c17a1fcdaa3
Author: Ma Ling <ling.ma@intel.com>
Date:   Wed Feb 18 17:41:26 2009 +0800

    EDID: CEA extension support
    
    Reviewed-by: Adam Jackson <ajax@redhat.com>

His recommendation is that we just use the KMS modes and not reparse the EDID in the ddx.

Sigh, xf86ProbeOutputModes() makes this hard.

Temporary hack:

diff --git a/hw/xfree86/ddc/interpret_edid.c b/hw/xfree86/ddc/interpret_edid.c
index acb7efa..46958f7 100644
--- a/hw/xfree86/ddc/interpret_edid.c
+++ b/hw/xfree86/ddc/interpret_edid.c
@@ -552,7 +552,7 @@ get_monitor_ranges(Uchar *c, struct monitor_ranges *r)
     r->max_h = MAX_H;
     r->max_clock = 0;
     if(MAX_CLOCK != 0xff) /* is specified? */
-       r->max_clock = MAX_CLOCK * 10;
+       r->max_clock = MAX_CLOCK * 10 + 5;
     if (HAVE_2ND_GTF) {
        r->gtf_2nd_f = F_2ND_GTF;
        r->gtf_2nd_c = C_2ND_GTF;

(In reply to comment #14)
> Temporary hack:
> 
> diff --git a/hw/xfree86/ddc/interpret_edid.c b/hw/xfree86/ddc/interpret_edid.c
> index acb7efa..46958f7 100644
> --- a/hw/xfree86/ddc/interpret_edid.c
> +++ b/hw/xfree86/ddc/interpret_edid.c
> @@ -552,7 +552,7 @@ get_monitor_ranges(Uchar *c, struct monitor_ranges *r)
>      r->max_h = MAX_H;
>      r->max_clock = 0;
>      if(MAX_CLOCK != 0xff) /* is specified? */
> -       r->max_clock = MAX_CLOCK * 10;
> +       r->max_clock = MAX_CLOCK * 10 + 5;
>      if (HAVE_2ND_GTF) {
>         r->gtf_2nd_f = F_2ND_GTF;
>         r->gtf_2nd_c = C_2ND_GTF;

I applied the patch to the xserver and now X also uses the 75Hz refresh and switch to VT is very fast. So what's the right refresh, 60Hz of unpatched X or 75Hz of kernel and patched X? Note that on the same machine Windows XP also uses 60Hz.

Anyway it would make sense that when using KMS X shouldn't change the resolution unless a different one is specified in the xorg.conf file.

> --- Comment #15 from Fabio Pedretti <fabio.ped@libero.it> 2010-08-19 23:49:03 PDT ---
> I applied the patch to the xserver and now X also uses the 75Hz refresh and
> switch to VT is very fast. So what's the right refresh, 60Hz of unpatched X or
> 75Hz of kernel and patched X? Note that on the same machine Windows XP also
> uses 60Hz.

The monitor lists the 75Hz amongst the detailed modes that it supports.
However, that mode conflicts with the EDID's maximum pixel clock, though
that is arguably due to limited accuracy of the field (and a rounding
error, on whose part the spec is unclear). As the monitor explicitly
supports the mode, we should be using it.

(In reply to comment #16)
> The monitor lists the 75Hz amongst the detailed modes that it supports.
> However, that mode conflicts with the EDID's maximum pixel clock, though
> that is arguably due to limited accuracy of the field (and a rounding
> error, on whose part the spec is unclear). As the monitor explicitly
> supports the mode, we should be using it.

OK, just for completeness I noticed that on Windows 70, 72, 75Hz are also selectable and work fine.

I have not found a clean way to simply use the KMS modes in X due to the ability of the user to override them. So let's go with the simple patch...

Patch is upstream for 1.9:

commit 951605b4660290044fb238bcf1d6d9e498567e8c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Aug 20 13:51:04 2010 +0100

    edid: Adjust rounding of max_clock

Does, by the way, using refresh rate > 60Hz on LCDs improve end user visual experience or not? I usually hears that LCDs work fine with 60Hz (also Windows default to it).