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

[Jon Masters]

On Mon, 2010-11-08 at 06:29 -0500, Jon Masters wrote:
> On Mon, 2010-11-08 at 06:22 -0500, Jon Masters wrote:
> > On Mon, 2010-11-08 at 05:54 -0500, Jon Masters wrote:
> > 
> > > Here is the EDID output after booting:
> > > 
> > > [jcm@monticello ~]$ hexdump /sys/class/drm/card0-LVDS-1/edid
> > > 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
> > 
> > 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:
> 
> Screen 0: minimum 320 x 200, current 1024 x 600, maximum 4096 x 4096
> LVDS1 connected 1024x600+0+0 (0x43) normal (normal left inverted right x
> axis y axis) 220mm x 129mm
> 	Identifier: 0x41
> 	Timestamp:  1402374
> 	Subpixel:   horizontal rgb
> 	Gamma:      1.0:1.0:1.0
> 	Brightness: 1.0
> 	Clones:    
> 	CRTC:       1
> 	CRTCs:      1
> 	Transform:  1.000000 0.000000 0.000000
> 	            0.000000 1.000000 0.000000
> 	            0.000000 0.000000 1.000000
> 	           filter: 
> 	EDID:
> 		00ffffffffffff002264e90344850100
> 		1c14010380160d780a86269457519027
> 		214f5400000001010101010101010101
> 		010101010101941100b0405819203523
> 		4500dc8100000019161400d840582620
> 		5d231504dc8100000000000000fe0000
> 		000000000000000000000000000000fe
> 		000000000000000000010000000000f2
> 	BACKLIGHT: 10 (0x0000000a)	range:  (0,10)
> 	Backlight: 10 (0x0000000a)	range:  (0,10)
> 	scaling mode:	Full aspect
> 		supported: None         Full         Center       Full aspect 
>   1024x600 (0x43)   45.0MHz -HSync -VSync *current +preferred
>         h: width  1024 start 1077 end 1112 total 1200 skew    0 clock
> 37.5KHz
>         v: height  600 start  604 end  609 total  625           clock
> 60.0Hz
>   1024x600 (0x44)   51.4MHz -HSync -VSync
>         h: width  1024 start 1117 end 1152 total 1240 skew    0 clock
> 41.5KHz
>         v: height  600 start  601 end  606 total  638           clock
> 65.0Hz
>   800x600 (0x45)   40.0MHz +HSync +VSync
>         h: width   800 start  840 end  968 total 1056 skew    0 clock
> 37.9KHz
>         v: height  600 start  601 end  605 total  628           clock
> 60.3Hz
>   800x600 (0x46)   36.0MHz +HSync +VSync
>         h: width   800 start  824 end  896 total 1024 skew    0 clock
> 35.2KHz
>         v: height  600 start  601 end  603 total  625           clock
> 56.2Hz
>   640x480 (0x47)   25.2MHz -HSync -VSync
>         h: width   640 start  656 end  752 total  800 skew    0 clock
> 31.5KHz
>         v: height  480 start  490 end  492 total  525           clock
> 59.9Hz
> VGA1 disconnected (normal left inverted right x axis y axis)
> 	Identifier: 0x42
> 	Timestamp:  1402374
> 	Subpixel:   unknown
> 	Clones:    
> 	CRTCs:      0 1
> 	Transform:  1.000000 0.000000 0.000000
> 	            0.000000 1.000000 0.000000
> 	            0.000000 0.000000 1.000000
> 	           filter: 

FWIW I don't recall seeing any reported difference in xrandr. I think
what I need is a hacked up debug patch if you can spin me one. Night!

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/