Re: [Intel-gfx] [bisected] offset display bug in i915

[Jon Masters]

On Mon, 2010-11-08 at 12:13 +0000, Chris Wilson wrote:
> On Mon, 08 Nov 2010 06:29:09 -0500, Jon Masters <jonathan@xxxxxxxxxxxxxx> wrote:
> > On Mon, 2010-11-08 at 06:22 -0500, Jon Masters wrote:
> > > As I mentioned on IRC, I'm familiar with how I2C works electrically, and
> > > therefore EDID implementation as a concept, but I am not really a
> > > graphics hacker so I wasn't aware that you prefer edid-decode :)
> > > 
> > > Here is a decoded version of the output:
> > 
> > And here is an old file I had with the output when running a broken
> > kernel with the cacheing enabled:
> 
> They look to be identical. So it is not necessarily the caching that is
> the issue, but that we now no longer do an essential step whilst bringing
> up the lvds. Can you just check that the reported EDIDs are the same for
> when it is behaving correctly and when the display is offset?

diff says they are the same. Here's the output from a broken kernel:

$ cat edid_broken_hexdump.txt 
0000000 ff00 ffff ffff 00ff 6422 03e9 8544 0001
0000010 141c 0301 1680 780d 860a 9426 5157 2790
0000020 4f21 0054 0000 0101 0101 0101 0101 0101
0000030 0101 0101 0101 1194 b000 5840 2019 2335
0000040 0045 81dc 0000 1900 1416 d800 5840 2026
0000050 235d 0415 81dc 0000 0000 0000 fe00 0000
0000060 0000 0000 0000 0000 0000 0000 0000 fe00
0000070 0000 0000 0000 0000 0100 0000 0000 f200
0000080

$ cat edid_broken_decode.txt
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   22 64 e9 03 44 85 01 00 1c 14
version:         01 03
basic params:    80 16 0d 78 0a
chroma info:     86 26 94 57 51 90 27 21 4f 54
established:     00 00 00
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    94 11 00 b0 40 58 19 20 35 23 45 00 dc 81 00 00 00 19
descriptor 2:    16 14 00 d8 40 58 26 20 5d 23 15 04 dc 81 00 00 00 00
descriptor 3:    00 00 00 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00
descriptor 4:    00 00 00 fe 00 00 00 00 00 00 00 00 00 01 00 00 00 00
extensions:      00
checksum:        f2

Manufacturer: HSD Model 3e9 Serial Number 99652
Made week 28 of 2010
EDID version: 1.3
Digital display
Maximum image size: 22 cm x 13 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4, YCrCb 4:2:2
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed mode: Clock 45.000 MHz, 220 mm x 129 mm
               1024 1077 1112 1200 hborder 0
                600  604  609  625 vborder 0
               -hsync -vsync
Detailed mode: Clock 51.420 MHz, 220 mm x 129 mm
               1024 1117 1152 1240 hborder 0
                600  617  622  638 vborder 0
               -hsync -vsync analog composite
ASCII string: ASCII string: Checksum: 0xf2
EDID block does NOT conform to EDID 1.3!
	Missing name descriptor
	Missing monitor ranges

> The secondary change in the commit was to use drm_get_edid() directly
> during device detection which delayed setting the EDID property on the
> connection until get_modes(). Does this make a difference?
> 
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds
> index f1a6499..17bcb7d 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -940,7 +940,10 @@ void intel_lvds_init(struct drm_device *dev)
>         intel_lvds->edid = drm_get_edid(connector,
>                                         &dev_priv->gmbus[pin].adapter);
>  
> -       if (!intel_lvds->edid) {
> +       if (intel_lvds->edid) {
> +               drm_mode_connector_update_edid_property(connector,
> +                                                       intel_lvds->edid);
> +       } else {

Nope. This makes no difference at all. Got anything else up your sleeve?

Jon.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/