* [bisected] offset display bug in i915
@ 2010-11-08 10:18 Jon Masters
2010-11-08 10:20 ` Jon Masters
2010-11-08 10:27 ` Chris Wilson
0 siblings, 2 replies; 27+ messages in thread
From: Jon Masters @ 2010-11-08 10:18 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List
Hi Chris,
The following patch that you recently committed breaks my ASUS Eee PC
1015PEM by causing the display to be offset by about 1 inch (a few
centimeters) when the mode is (re)set during boot. I previously posted
both photographs and video of the problem in another "PROBLEM" thread.
Here is the offending commit found through bisection:
219adae138513bae20b256f1946b9cb3b75ca05c is the first bad commit
commit 219adae138513bae20b256f1946b9cb3b75ca05c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Sep 16 23:05:10 2010 +0100
drm/i915: Cache LVDS EDID
We assume that the panel is permenantly connected and that the EDID
data is consistent from boot, so simply cache the whole EDID for the
panel.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I'll look at the patch. Either the EDID is *not* consistent (in which
case, why are we not seeing other bugs like this?) or there is something
specific to this system or panel used.
Jon.
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [Intel-gfx] [bisected] offset display bug in i915 2010-11-08 10:18 [bisected] offset display bug in i915 Jon Masters @ 2010-11-08 10:20 ` Jon Masters 2010-11-08 10:27 ` Chris Wilson 1 sibling, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-08 10:20 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List On Mon, 2010-11-08 at 05:18 -0500, Jon Masters wrote: > The following patch that you recently committed breaks my ASUS Eee PC > 1015PEM by causing the display to be offset by about 1 inch (a few > centimeters) when the mode is (re)set during boot. I previously posted > both photographs and video of the problem in another "PROBLEM" thread. Here's my bisection log, for the record. git bisect start # good: [f6f94e2ab1b33f0082ac22d71f66385a60d8157f] Linux 2.6.36 git bisect good f6f94e2ab1b33f0082ac22d71f66385a60d8157f # bad: [c8ddb2713c624f432fa5fe3c7ecffcdda46ea0d4] Linux 2.6.37-rc1 git bisect bad c8ddb2713c624f432fa5fe3c7ecffcdda46ea0d4 # good: [33081adf8b89d5a716d7e1c60171768d39795b39] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6 git bisect good 33081adf8b89d5a716d7e1c60171768d39795b39 # bad: [00ebb6382b8d9c7c15b5f8ad230670d8161d38dd] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc git bisect bad 00ebb6382b8d9c7c15b5f8ad230670d8161d38dd # good: [520045db940a381d2bee1c1b2179f7921b40fb10] Merge branches 'upstream/xenfs' and 'upstream/core' of git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen git bisect good 520045db940a381d2bee1c1b2179f7921b40fb10 # bad: [60ee6d5faf5f7920ba88b82c072864596f5b88af] ipmi: fix __init and __exit attribute locations git bisect bad 60ee6d5faf5f7920ba88b82c072864596f5b88af # bad: [e6b46ee712b92db1cc2449cf4f65bc635366cad4] Merge branch 'drm-vmware-next' into drm-core-next git bisect bad e6b46ee712b92db1cc2449cf4f65bc635366cad4 # good: [f7abfe8b281991c66406c42c1a6c6c9ee0daa0ff] drm/i915: Fix an overlay regression from 7e7d76c git bisect good f7abfe8b281991c66406c42c1a6c6c9ee0daa0ff # bad: [9e0ae53404700f1e4ae1f33b0ff92948ae0e509d] drm/i915: Don't overwrite the returned error-code git bisect bad 9e0ae53404700f1e4ae1f33b0ff92948ae0e509d # bad: [881f47b64723f4d697084533491a489e3e74b10f] drm/i915: add a new BSD ring buffer for Sandybridge git bisect bad 881f47b64723f4d697084533491a489e3e74b10f # good: [f899fc64cda8569d0529452aafc0da31c042df2e] drm/i915: use GMBUS to manage i2c links git bisect good f899fc64cda8569d0529452aafc0da31c042df2e # bad: [b84d5f0c22914d37d709add54c66e741c404fa56] drm/i915: Inline i915_gem_ring_retire_request() git bisect bad b84d5f0c22914d37d709add54c66e741c404fa56 # bad: [f49f0586191fe16140410db0a46d43bdc690d6af] drm/i915: Actually set the reset bit in i965_reset. git bisect bad f49f0586191fe16140410db0a46d43bdc690d6af # bad: [219adae138513bae20b256f1946b9cb3b75ca05c] drm/i915: Cache LVDS EDID git bisect bad 219adae138513bae20b256f1946b9cb3b75ca05c # good: [e9e5f8e8d373e72f5c39dafde1ce110fc7082118] Merge branch 'drm-intel-fixes' into HEAD git bisect good e9e5f8e8d373e72f5c39dafde1ce110fc7082118 Jon. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [bisected] offset display bug in i915 @ 2010-11-08 10:20 ` Jon Masters 0 siblings, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-08 10:20 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List On Mon, 2010-11-08 at 05:18 -0500, Jon Masters wrote: > The following patch that you recently committed breaks my ASUS Eee PC > 1015PEM by causing the display to be offset by about 1 inch (a few > centimeters) when the mode is (re)set during boot. I previously posted > both photographs and video of the problem in another "PROBLEM" thread. Here's my bisection log, for the record. git bisect start # good: [f6f94e2ab1b33f0082ac22d71f66385a60d8157f] Linux 2.6.36 git bisect good f6f94e2ab1b33f0082ac22d71f66385a60d8157f # bad: [c8ddb2713c624f432fa5fe3c7ecffcdda46ea0d4] Linux 2.6.37-rc1 git bisect bad c8ddb2713c624f432fa5fe3c7ecffcdda46ea0d4 # good: [33081adf8b89d5a716d7e1c60171768d39795b39] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6 git bisect good 33081adf8b89d5a716d7e1c60171768d39795b39 # bad: [00ebb6382b8d9c7c15b5f8ad230670d8161d38dd] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc git bisect bad 00ebb6382b8d9c7c15b5f8ad230670d8161d38dd # good: [520045db940a381d2bee1c1b2179f7921b40fb10] Merge branches 'upstream/xenfs' and 'upstream/core' of git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen git bisect good 520045db940a381d2bee1c1b2179f7921b40fb10 # bad: [60ee6d5faf5f7920ba88b82c072864596f5b88af] ipmi: fix __init and __exit attribute locations git bisect bad 60ee6d5faf5f7920ba88b82c072864596f5b88af # bad: [e6b46ee712b92db1cc2449cf4f65bc635366cad4] Merge branch 'drm-vmware-next' into drm-core-next git bisect bad e6b46ee712b92db1cc2449cf4f65bc635366cad4 # good: [f7abfe8b281991c66406c42c1a6c6c9ee0daa0ff] drm/i915: Fix an overlay regression from 7e7d76c git bisect good f7abfe8b281991c66406c42c1a6c6c9ee0daa0ff # bad: [9e0ae53404700f1e4ae1f33b0ff92948ae0e509d] drm/i915: Don't overwrite the returned error-code git bisect bad 9e0ae53404700f1e4ae1f33b0ff92948ae0e509d # bad: [881f47b64723f4d697084533491a489e3e74b10f] drm/i915: add a new BSD ring buffer for Sandybridge git bisect bad 881f47b64723f4d697084533491a489e3e74b10f # good: [f899fc64cda8569d0529452aafc0da31c042df2e] drm/i915: use GMBUS to manage i2c links git bisect good f899fc64cda8569d0529452aafc0da31c042df2e # bad: [b84d5f0c22914d37d709add54c66e741c404fa56] drm/i915: Inline i915_gem_ring_retire_request() git bisect bad b84d5f0c22914d37d709add54c66e741c404fa56 # bad: [f49f0586191fe16140410db0a46d43bdc690d6af] drm/i915: Actually set the reset bit in i965_reset. git bisect bad f49f0586191fe16140410db0a46d43bdc690d6af # bad: [219adae138513bae20b256f1946b9cb3b75ca05c] drm/i915: Cache LVDS EDID git bisect bad 219adae138513bae20b256f1946b9cb3b75ca05c # good: [e9e5f8e8d373e72f5c39dafde1ce110fc7082118] Merge branch 'drm-intel-fixes' into HEAD git bisect good e9e5f8e8d373e72f5c39dafde1ce110fc7082118 Jon. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [bisected] offset display bug in i915 2010-11-08 10:18 [bisected] offset display bug in i915 Jon Masters 2010-11-08 10:20 ` Jon Masters @ 2010-11-08 10:27 ` Chris Wilson 2010-11-08 10:54 ` Jon Masters 2010-11-08 11:26 ` James Courtier-Dutton 1 sibling, 2 replies; 27+ messages in thread From: Chris Wilson @ 2010-11-08 10:27 UTC (permalink / raw) To: Jon Masters; +Cc: intel-gfx, Linux Kernel Mailing List On Mon, 08 Nov 2010 05:18:32 -0500, Jon Masters <jonathan@jonmasters.org> wrote: > Hi Chris, > > The following patch that you recently committed breaks my ASUS Eee PC > 1015PEM by causing the display to be offset by about 1 inch (a few > centimeters) when the mode is (re)set during boot. I previously posted > both photographs and video of the problem in another "PROBLEM" thread. [snip] > I'll look at the patch. Either the EDID is *not* consistent (in which > case, why are we not seeing other bugs like this?) or there is something > specific to this system or panel used. Interesting. Or even downright bizarre! Can you disable the caching (hopefully the patch is still revertible) and save the EDID (/sys/class/drm/card0-LVDS-1/edid) periodically? Might be simplest just to dump the EDID every time we probe the LVDS if it has changed. -Chris -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [bisected] offset display bug in i915 2010-11-08 10:27 ` Chris Wilson @ 2010-11-08 10:54 ` Jon Masters 2010-11-08 11:22 ` Jon Masters 2010-11-08 11:33 ` [bisected] offset display bug in i915 James Courtier-Dutton 2010-11-08 11:26 ` James Courtier-Dutton 1 sibling, 2 replies; 27+ messages in thread From: Jon Masters @ 2010-11-08 10:54 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List On Mon, 2010-11-08 at 10:27 +0000, Chris Wilson wrote: > On Mon, 08 Nov 2010 05:18:32 -0500, Jon Masters <jonathan@jonmasters.org> wrote: > > Hi Chris, > > > > The following patch that you recently committed breaks my ASUS Eee PC > > 1015PEM by causing the display to be offset by about 1 inch (a few > > centimeters) when the mode is (re)set during boot. I previously posted > > both photographs and video of the problem in another "PROBLEM" thread. > > [snip] > > > I'll look at the patch. Either the EDID is *not* consistent (in which > > case, why are we not seeing other bugs like this?) or there is something > > specific to this system or panel used. > > Interesting. Or even downright bizarre! Can you disable the caching > (hopefully the patch is still revertible) and save the EDID > (/sys/class/drm/card0-LVDS-1/edid) periodically? Might be simplest just to > dump the EDID every time we probe the LVDS if it has changed. Already onto it. It's 6am here so I'll sleep soon ;) but I just applied the following patch and booted it/logged into X without the problem (apologies if evolution corrupts it, I usually send patches with mutt): >From c2fed0d864935603b1d71c71ae53d197f52e346f Mon Sep 17 00:00:00 2001 From: Jon Masters <jcm@jonmasters.org> Date: Mon, 8 Nov 2010 05:39:42 -0500 Subject: [PATCH] drm/i915: revert LVDS EDID cacheing The previous commit v2.6.36-rc5-173-g219adae changed the Intel i915 driver to cache the EDID result obtained from the panel, but in so doing broke some systems by causing weird modesetting problems. Signed-off-by: Jon Masters <jcm@jonmasters.org> --- drivers/gpu/drm/i915/intel_lvds.c | 19 +++++++++++-------- 1 files changed, 11 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index f1a6499..78153df 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -44,7 +44,7 @@ struct intel_lvds { struct intel_encoder base; - struct edid *edid; + bool edid_good; int fitting_mode; u32 pfit_control; @@ -479,12 +479,14 @@ static int intel_lvds_get_modes(struct drm_connector *connector) { struct intel_lvds *intel_lvds = intel_attached_lvds(connector); struct drm_device *dev = connector->dev; + struct drm_i915_private *dev_priv = dev->dev_private; struct drm_display_mode *mode; - if (intel_lvds->edid) { - drm_mode_connector_update_edid_property(connector, - intel_lvds->edid); - return drm_add_edid_modes(connector, intel_lvds->edid); + if (intel_lvds->edid_good) { + int ret = intel_ddc_get_modes(connector, + &dev_priv->gmbus[GMBUS_PORT_PANEL].adapter); + if (ret) + return ret; } mode = drm_mode_duplicate(dev, intel_lvds->fixed_mode); @@ -937,10 +939,11 @@ void intel_lvds_init(struct drm_device *dev) * Attempt to get the fixed panel mode from DDC. Assume that the * preferred mode is the right one. */ - intel_lvds->edid = drm_get_edid(connector, - &dev_priv->gmbus[pin].adapter); + intel_lvds->edid_good = true; + if (!intel_ddc_get_modes(connector, &dev_priv->gmbus[GMBUS_PORT_PANEL].adapter)) + intel_lvds->edid_good = false; - if (!intel_lvds->edid) { + if (!intel_lvds->edid_good) { /* Didn't get an EDID, so * Set wide sync ranges so we get all modes * handed to valid_mode for checking -- 1.7.3.2 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 Sounds like you are suggesting that I hack up the intel_lvds to just printk the EDID when it is read? I can look at that, probably after sleeping. Perhaps you can also send me a patch to get what you want? I'm on IRC, and pingable later on today if you want me to try stuff. Jon. ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [Intel-gfx] [bisected] offset display bug in i915 2010-11-08 10:54 ` Jon Masters @ 2010-11-08 11:22 ` Jon Masters 2010-11-08 11:33 ` [bisected] offset display bug in i915 James Courtier-Dutton 1 sibling, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-08 11:22 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List 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: 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 If you send me a hacked up patch that dumps out whatever you want in the kernel ringbugger, I'll build and run it for you. Presumably you are expecting some of the reported geometry to vary, etc. Here is the output from xrandr FWIW (but as I mentioned, this is happening way before X gets its hands on the scene): [jcm@monticello ~]$ xrandr --verbose 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: 337852 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: 337852 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: Jon. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [bisected] offset display bug in i915 @ 2010-11-08 11:22 ` Jon Masters 0 siblings, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-08 11:22 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List 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: 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 If you send me a hacked up patch that dumps out whatever you want in the kernel ringbugger, I'll build and run it for you. Presumably you are expecting some of the reported geometry to vary, etc. Here is the output from xrandr FWIW (but as I mentioned, this is happening way before X gets its hands on the scene): [jcm@monticello ~]$ xrandr --verbose 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: 337852 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: 337852 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: Jon. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Intel-gfx] [bisected] offset display bug in i915 2010-11-08 11:22 ` Jon Masters @ 2010-11-08 11:29 ` Jon Masters -1 siblings, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-08 11:29 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List 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: Jon. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [bisected] offset display bug in i915 @ 2010-11-08 11:29 ` Jon Masters 0 siblings, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-08 11:29 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List 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: Jon. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Intel-gfx] [bisected] offset display bug in i915 2010-11-08 11:29 ` Jon Masters @ 2010-11-08 11:36 ` Jon Masters -1 siblings, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-08 11:36 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [bisected] offset display bug in i915 @ 2010-11-08 11:36 ` Jon Masters 0 siblings, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-08 11:36 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Intel-gfx] [bisected] offset display bug in i915 2010-11-08 11:29 ` Jon Masters @ 2010-11-08 12:13 ` Chris Wilson -1 siblings, 0 replies; 27+ messages in thread From: Chris Wilson @ 2010-11-08 12:13 UTC (permalink / raw) To: Jon Masters; +Cc: intel-gfx, Linux Kernel Mailing List On Mon, 08 Nov 2010 06:29:09 -0500, Jon Masters <jonathan@jonmasters.org> 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? 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 { -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [bisected] offset display bug in i915 @ 2010-11-08 12:13 ` Chris Wilson 0 siblings, 0 replies; 27+ messages in thread From: Chris Wilson @ 2010-11-08 12:13 UTC (permalink / raw) To: Jon Masters; +Cc: intel-gfx, Linux Kernel Mailing List On Mon, 08 Nov 2010 06:29:09 -0500, Jon Masters <jonathan@jonmasters.org> 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? 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 { -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [Intel-gfx] [bisected] offset display bug in i915 2010-11-08 12:13 ` Chris Wilson @ 2010-11-08 17:58 ` Jon Masters -1 siblings, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-08 17:58 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List On Mon, 2010-11-08 at 12:13 +0000, Chris Wilson wrote: > On Mon, 08 Nov 2010 06:29:09 -0500, Jon Masters <jonathan@jonmasters.org> 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [bisected] offset display bug in i915 @ 2010-11-08 17:58 ` Jon Masters 0 siblings, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-08 17:58 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List On Mon, 2010-11-08 at 12:13 +0000, Chris Wilson wrote: > On Mon, 08 Nov 2010 06:29:09 -0500, Jon Masters <jonathan@jonmasters.org> 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Intel-gfx] [bisected] offset display bug in i915 2010-11-08 12:13 ` Chris Wilson @ 2010-11-08 23:08 ` Jon Masters -1 siblings, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-08 23:08 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List On Mon, 2010-11-08 at 12:13 +0000, Chris Wilson wrote: > On Mon, 08 Nov 2010 06:29:09 -0500, Jon Masters <jonathan@jonmasters.org> 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? > > 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 { I tried this, which didn't work. Then I added this (ignore stupid evolution formatting - convenient for email backlog, but not mutt): diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index 17bcb7d..a0bb443 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -462,6 +462,14 @@ intel_lvds_detect(struct drm_connector *connector, bool force) { struct drm_device *dev = connector->dev; enum drm_connector_status status = connector_status_connected; + /* JCM - added this */ + struct drm_i915_private *dev_priv = dev->dev_private; + u8 pin = GMBUS_PORT_PANEL; + struct edid *edid = drm_get_edid(connector, &dev_priv->gmbus[pin].adapter); + + /* I was asked to free in here */ + if (edid) + kfree(edid); /* ACPI lid methods were generally unreliable in this generation, so * don't even bother. Which should have made the edid always get freed on detect. That didn't work either. I might wind up learning something about the DRM stack. Anyway. Here's the reg dumper output. First, for a busticated kernel: [jcm@constitution ~]$ cat intel_regs_broken.txt DCC: 0x00200020 (single channel, XOR randomization: enabled, XOR bit: 11) CHDECMISC: 0x42000064 (XOR bank, ch2 enh disabled, ch1 enh disabled, ch0 enh enabled, flex disabled, ep not present) C0DRB0: 0x00200020 (0x0020) C0DRB1: 0x00200020 (0x0020) C0DRB2: 0x00200020 (0x0020) C0DRB3: 0x00880020 (0x0020) C1DRB0: 0x00000000 (0x0000) C1DRB1: 0x00000000 (0x0000) C1DRB2: 0x00000000 (0x0000) C1DRB3: 0x00000000 (0x0000) C0DRA01: 0x00000088 (0x0088) C0DRA23: 0x00000000 (0x0000) C1DRA01: 0x00000000 (0x0000) C1DRA23: 0x00000000 (0x0000) PGETBL_CTL: 0x00000001 VCLK_DIVISOR_VGA0: 0x00200074 (n = 32, m1 = 0, m2 = 52) VCLK_DIVISOR_VGA1: 0x00200074 (n = 32, m1 = 0, m2 = 52) VCLK_POST_DIV: 0x00800100 (vga0 p1 = 2, p2 = 2, vga1 p1 = 3, p2 = 2) DPLL_TEST: 0x00010001 () CACHE_MODE_0: 0x00006820 D_STATE: 0x0000000b DSPCLK_GATE_D: 0x00000000 (clock gates disabled:) RENCLK_GATE_D1: 0x00000000 RENCLK_GATE_D2: 0x00000000 SDVOB: 0x00300000 (disabled, pipe A, stall disabled, not detected) SDVOC: 0x00300000 (disabled, pipe A, stall disabled, not detected) SDVOUDI: 0x00000000 DSPARB: 0x00001d9c DSPFW1: 0xf1830f0f DSPFW2: 0x0000030f DSPFW3: 0x6700018f ADPA: 0x40008c18 (disabled, pipe B, +hsync, +vsync) LVDS: 0xc0308300 (enabled, pipe B, 18 bit, 1 channel) DVOA: 0x00000000 (disabled, pipe A, no stall, -hsync, -vsync) DVOB: 0x00300000 (disabled, pipe A, no stall, -hsync, -vsync) DVOC: 0x00300000 (disabled, pipe A, no stall, -hsync, -vsync) DVOA_SRCDIM: 0x00000000 DVOB_SRCDIM: 0x00000000 DVOC_SRCDIM: 0x00000000 PP_CONTROL: 0x00000001 (power target: on) PP_STATUS: 0xc0000008 (on, ready, sequencing idle) PP_ON_DELAYS: 0x025807d0 PP_OFF_DELAYS: 0x01f407d0 PP_DIVISOR: 0x00209d05 PFIT_CONTROL: 0x00000008 PFIT_PGM_RATIOS: 0x00000000 PORT_HOTPLUG_EN: 0x00000220 PORT_HOTPLUG_STAT: 0x00001000 DSPACNTR: 0xd9000000 (enabled, pipe B) DSPASTRIDE: 0x00001000 (4096 bytes) DSPAPOS: 0x00000000 (0, 0) DSPASIZE: 0x025703ff (1024, 600) DSPABASE: 0x00830000 DSPASURF: 0x00000000 DSPATILEOFF: 0x00000000 PIPEACONF: 0x00000000 (disabled, single-wide) PIPEASRC: 0x027f01df (640, 480) PIPEASTAT: 0x00000000 (status:) PIPEA_GMCH_DATA_M: 0x00000000 PIPEA_GMCH_DATA_N: 0x00000000 PIPEA_DP_LINK_M: 0x00000000 PIPEA_DP_LINK_N: 0x00000000 CURSOR_A_BASE: 0x00000000 CURSOR_A_CONTROL: 0x00000000 CURSOR_A_POSITION: 0x00000000 FPA0: 0x00200074 (n = 32, m1 = 0, m2 = 52) FPA1: 0x00200074 (n = 32, m1 = 0, m2 = 52) DPLL_A: 0x04800000 (disabled, non-dvo, VGA, default clock, DAC/serial mode, p1 = 9, p2 = 10, SDVO mult 1) DPLL_A_MD: 0x00000000 HTOTAL_A: 0x031f027f (640 active, 800 total) HBLANK_A: 0x03170287 (648 start, 792 end) HSYNC_A: 0x02ef028f (656 start, 752 end) VTOTAL_A: 0x020c01df (480 active, 525 total) VBLANK_A: 0x020401e7 (488 start, 517 end) VSYNC_A: 0x01eb01e9 (490 start, 492 end) BCLRPAT_A: 0x00000000 VSYNCSHIFT_A: 0x00000000 DSPBCNTR: 0x49000000 (disabled, pipe B) DSPBSTRIDE: 0x00000280 (640 bytes) DSPBPOS: 0x00000000 (0, 0) DSPBSIZE: 0x018f02cf (720, 400) DSPBBASE: 0x00000000 DSPBSURF: 0x00000000 DSPBTILEOFF: 0x00000000 PIPEBCONF: 0x80000000 (enabled, single-wide) PIPEBSRC: 0x03ff0257 (1024, 600) PIPEBSTAT: 0x00400202 (status: LBLC_EVENT_ENABLE VSYNC_INT_STATUS VBLANK_INT_STATUS) PIPEB_GMCH_DATA_M: 0x00000000 PIPEB_GMCH_DATA_N: 0x00000000 PIPEB_DP_LINK_M: 0x00000000 PIPEB_DP_LINK_N: 0x00000000 CURSOR_B_BASE: 0x00000000 CURSOR_B_CONTROL: 0x10000000 CURSOR_B_POSITION: 0x012801f9 FPB0: 0x0020008c (n = 32, m1 = 0, m2 = 12) FPB1: 0x0020008c (n = 32, m1 = 0, m2 = 12) DPLL_B: 0x98020000 (enabled, non-dvo, default clock, LVDS mode, p1 = 3, p2 = 14, SDVO mult 1) DPLL_B_MD: 0x00000000 HTOTAL_B: 0x053f03ff (1024 active, 1344 total) HBLANK_B: 0x053f03ff (1024 start, 1344 end) HSYNC_B: 0x049f0417 (1048 start, 1184 end) VTOTAL_B: 0x03250257 (600 active, 806 total) VBLANK_B: 0x02d102ab (684 start, 722 end) VSYNC_B: 0x02c102bb (700 start, 706 end) BCLRPAT_B: 0x00000000 VSYNCSHIFT_B: 0x00000000 VCLK_DIVISOR_VGA0: 0x00200074 VCLK_DIVISOR_VGA1: 0x00200074 VCLK_POST_DIV: 0x00800100 VGACNTRL: 0x80000000 (disabled) TV_CTL: 0x00000000 TV_DAC: 0x00000000 TV_CSC_Y: 0x00000000 TV_CSC_Y2: 0x00000000 TV_CSC_U: 0x00000000 TV_CSC_U2: 0x00000000 TV_CSC_V: 0x00000000 TV_CSC_V2: 0x00000000 TV_CLR_KNOBS: 0x00000000 TV_CLR_LEVEL: 0x00000000 TV_H_CTL_1: 0x00000000 TV_H_CTL_2: 0x00000000 TV_H_CTL_3: 0x00000000 TV_V_CTL_1: 0x00000000 TV_V_CTL_2: 0x00000000 TV_V_CTL_3: 0x00000000 TV_V_CTL_4: 0x00000000 TV_V_CTL_5: 0x00000000 TV_V_CTL_6: 0x00000000 TV_V_CTL_7: 0x00000000 TV_SC_CTL_1: 0x00000000 TV_SC_CTL_2: 0x00000000 TV_SC_CTL_3: 0x00000000 TV_WIN_POS: 0x00000000 TV_WIN_SIZE: 0x00000000 TV_FILTER_CTL_1: 0x00000000 TV_FILTER_CTL_2: 0x00000000 TV_FILTER_CTL_3: 0x00000000 TV_CC_CONTROL: 0x00000000 TV_CC_DATA: 0x00000000 TV_H_LUMA_0: 0x00000000 TV_H_LUMA_59: 0x00000000 TV_H_CHROMA_0: 0x00000000 TV_H_CHROMA_59: 0x00000000 FBC_CFB_BASE: 0xffffffff FBC_LL_BASE: 0xffffffff FBC_CONTROL: 0xffffffff FBC_COMMAND: 0xffffffff FBC_STATUS: 0xffffffff FBC_CONTROL2: 0xffffffff FBC_FENCE_OFF: 0xffffffff FBC_MOD_NUM: 0xffffffff MI_MODE: 0x00000200 MI_ARB_STATE: 0x00000840 MI_RDRET_STATE: 0x00000000 ECOSKPD: 0x00000307 DP_B: 0x00000000 DPB_AUX_CH_CTL: 0x00000000 DPB_AUX_CH_DATA1: 0x00000000 DPB_AUX_CH_DATA2: 0x00000000 DPB_AUX_CH_DATA3: 0x00000000 DPB_AUX_CH_DATA4: 0x00000000 DPB_AUX_CH_DATA5: 0x00000000 DP_C: 0x00000000 DPC_AUX_CH_CTL: 0x00000000 DPC_AUX_CH_DATA1: 0x00000000 DPC_AUX_CH_DATA2: 0x00000000 DPC_AUX_CH_DATA3: 0x00000000 DPC_AUX_CH_DATA4: 0x00000000 DPC_AUX_CH_DATA5: 0x00000000 DP_D: 0x00000000 DPD_AUX_CH_CTL: 0x00000000 DPD_AUX_CH_DATA1: 0x00000000 DPD_AUX_CH_DATA2: 0x00000000 DPD_AUX_CH_DATA3: 0x00000000 DPD_AUX_CH_DATA4: 0x00000000 DPD_AUX_CH_DATA5: 0x00000000 AUD_CONFIG: 0x00000000 AUD_HDMIW_STATUS: 0x00000000 AUD_CONV_CHCNT: 0x00000000 VIDEO_DIP_CTL: 0x00000000 AUD_PINW_CNTR: 0x00000000 AUD_CNTL_ST: 0x00000000 AUD_PIN_CAP: 0x00000000 AUD_PINW_CAP: 0x00000000 AUD_PINW_UNSOLRESP: 0x00000000 AUD_OUT_DIG_CNVT: 0x00000000 AUD_OUT_CWCAP: 0x00000000 AUD_GRP_CAP: 0x00000000 FENCE 0: 0x00c00231 (enabled, X tiled, 4096 pitch, 0x00c00000 - 0x01000000 (4096kb)) FENCE 1: 0x01000231 (enabled, X tiled, 4096 pitch, 0x01000000 - 0x01400000 (4096kb)) FENCE 2: 0x00000000 (disabled) FENCE 3: 0x00000000 (disabled) FENCE 4: 0x00000000 (disabled) FENCE 5: 0x00000000 (disabled) FENCE 6: 0x00000000 (disabled) FENCE 7: 0x00000000 (disabled) FENCE 8: 0x00000000 (disabled) FENCE 9: 0x00000000 (disabled) FENCE 10: 0x00000000 (disabled) FENCE 11: 0x00000000 (disabled) FENCE 12: 0x00000000 (disabled) FENCE 13: 0x00000000 (disabled) FENCE 14: 0x00000000 (disabled) FENCE 15: 0x00000000 (disabled) INST_PM: 0x00000000 pipe A dot 25173 n 5 m1 0 m2 116 p1 9 p2 10 pipe B dot 64914 n 5 m1 0 m2 140 p1 3 p2 14 And here for a non-busticated kernel: [jcm@constitution ~]$ cat intel_regs_works.txt DCC: 0x00200020 (single channel, XOR randomization: enabled, XOR bit: 11) CHDECMISC: 0x42000064 (XOR bank, ch2 enh disabled, ch1 enh disabled, ch0 enh enabled, flex disabled, ep not present) C0DRB0: 0x00200020 (0x0020) C0DRB1: 0x00200020 (0x0020) C0DRB2: 0x00200020 (0x0020) C0DRB3: 0x00880020 (0x0020) C1DRB0: 0x00000000 (0x0000) C1DRB1: 0x00000000 (0x0000) C1DRB2: 0x00000000 (0x0000) C1DRB3: 0x00000000 (0x0000) C0DRA01: 0x00000088 (0x0088) C0DRA23: 0x00000000 (0x0000) C1DRA01: 0x00000000 (0x0000) C1DRA23: 0x00000000 (0x0000) PGETBL_CTL: 0x00000001 VCLK_DIVISOR_VGA0: 0x00200074 (n = 32, m1 = 0, m2 = 52) VCLK_DIVISOR_VGA1: 0x00200074 (n = 32, m1 = 0, m2 = 52) VCLK_POST_DIV: 0x00800100 (vga0 p1 = 2, p2 = 2, vga1 p1 = 3, p2 = 2) DPLL_TEST: 0x00010001 () CACHE_MODE_0: 0x00006820 D_STATE: 0x0000000b DSPCLK_GATE_D: 0x00000000 (clock gates disabled:) RENCLK_GATE_D1: 0x00000000 RENCLK_GATE_D2: 0x00000000 SDVOB: 0x00300000 (disabled, pipe A, stall disabled, not detected) SDVOC: 0x00300000 (disabled, pipe A, stall disabled, not detected) SDVOUDI: 0x00000000 DSPARB: 0x00001d9c DSPFW1: 0xf1830f0f DSPFW2: 0x0000030f DSPFW3: 0x6700018f ADPA: 0x40008c18 (disabled, pipe B, +hsync, +vsync) LVDS: 0xc0300300 (enabled, pipe B, 18 bit, 1 channel) DVOA: 0x00000000 (disabled, pipe A, no stall, -hsync, -vsync) DVOB: 0x00300000 (disabled, pipe A, no stall, -hsync, -vsync) DVOC: 0x00300000 (disabled, pipe A, no stall, -hsync, -vsync) DVOA_SRCDIM: 0x00000000 DVOB_SRCDIM: 0x00000000 DVOC_SRCDIM: 0x00000000 PP_CONTROL: 0x00000001 (power target: on) PP_STATUS: 0xc0000008 (on, ready, sequencing idle) PP_ON_DELAYS: 0x025807d0 PP_OFF_DELAYS: 0x01f407d0 PP_DIVISOR: 0x00209d05 PFIT_CONTROL: 0x00000008 PFIT_PGM_RATIOS: 0x00000000 PORT_HOTPLUG_EN: 0x00000220 PORT_HOTPLUG_STAT: 0x00001000 DSPACNTR: 0xd9000000 (enabled, pipe B) DSPASTRIDE: 0x00001000 (4096 bytes) DSPAPOS: 0x00000000 (0, 0) DSPASIZE: 0x025703ff (1024, 600) DSPABASE: 0x00830000 DSPASURF: 0x00000000 DSPATILEOFF: 0x00000000 PIPEACONF: 0x00000000 (disabled, single-wide) PIPEASRC: 0x027f01df (640, 480) PIPEASTAT: 0x00000000 (status:) PIPEA_GMCH_DATA_M: 0x00000000 PIPEA_GMCH_DATA_N: 0x00000000 PIPEA_DP_LINK_M: 0x00000000 PIPEA_DP_LINK_N: 0x00000000 CURSOR_A_BASE: 0x00000000 CURSOR_A_CONTROL: 0x00000000 CURSOR_A_POSITION: 0x00000000 FPA0: 0x00200074 (n = 32, m1 = 0, m2 = 52) FPA1: 0x00200074 (n = 32, m1 = 0, m2 = 52) DPLL_A: 0x04800000 (disabled, non-dvo, VGA, default clock, DAC/serial mode, p1 = 9, p2 = 10, SDVO mult 1) DPLL_A_MD: 0x00000000 HTOTAL_A: 0x031f027f (640 active, 800 total) HBLANK_A: 0x03170287 (648 start, 792 end) HSYNC_A: 0x02ef028f (656 start, 752 end) VTOTAL_A: 0x020c01df (480 active, 525 total) VBLANK_A: 0x020401e7 (488 start, 517 end) VSYNC_A: 0x01eb01e9 (490 start, 492 end) BCLRPAT_A: 0x00000000 VSYNCSHIFT_A: 0x00000000 DSPBCNTR: 0x49000000 (disabled, pipe B) DSPBSTRIDE: 0x00000280 (640 bytes) DSPBPOS: 0x00000000 (0, 0) DSPBSIZE: 0x018f02cf (720, 400) DSPBBASE: 0x00000000 DSPBSURF: 0x00000000 DSPBTILEOFF: 0x00000000 PIPEBCONF: 0x80000000 (enabled, single-wide) PIPEBSRC: 0x03ff0257 (1024, 600) PIPEBSTAT: 0x00400202 (status: LBLC_EVENT_ENABLE VSYNC_INT_STATUS VBLANK_INT_STATUS) PIPEB_GMCH_DATA_M: 0x00000000 PIPEB_GMCH_DATA_N: 0x00000000 PIPEB_DP_LINK_M: 0x00000000 PIPEB_DP_LINK_N: 0x00000000 CURSOR_B_BASE: 0x00000000 CURSOR_B_CONTROL: 0x10000000 CURSOR_B_POSITION: 0x012801f9 FPB0: 0x00100067 (n = 16, m1 = 0, m2 = 39) FPB1: 0x00100067 (n = 16, m1 = 0, m2 = 39) DPLL_B: 0x98040000 (enabled, non-dvo, default clock, LVDS mode, p1 = 4, p2 = 14, SDVO mult 1) DPLL_B_MD: 0x00000000 HTOTAL_B: 0x04af03ff (1024 active, 1200 total) HBLANK_B: 0x04af03ff (1024 start, 1200 end) HSYNC_B: 0x04570434 (1077 start, 1112 end) VTOTAL_B: 0x02700257 (600 active, 625 total) VBLANK_B: 0x02700257 (600 start, 625 end) VSYNC_B: 0x0260025b (604 start, 609 end) BCLRPAT_B: 0x00000000 VSYNCSHIFT_B: 0x00000000 VCLK_DIVISOR_VGA0: 0x00200074 VCLK_DIVISOR_VGA1: 0x00200074 VCLK_POST_DIV: 0x00800100 VGACNTRL: 0x80000000 (disabled) TV_CTL: 0x00000000 TV_DAC: 0x00000000 TV_CSC_Y: 0x00000000 TV_CSC_Y2: 0x00000000 TV_CSC_U: 0x00000000 TV_CSC_U2: 0x00000000 TV_CSC_V: 0x00000000 TV_CSC_V2: 0x00000000 TV_CLR_KNOBS: 0x00000000 TV_CLR_LEVEL: 0x00000000 TV_H_CTL_1: 0x00000000 TV_H_CTL_2: 0x00000000 TV_H_CTL_3: 0x00000000 TV_V_CTL_1: 0x00000000 TV_V_CTL_2: 0x00000000 TV_V_CTL_3: 0x00000000 TV_V_CTL_4: 0x00000000 TV_V_CTL_5: 0x00000000 TV_V_CTL_6: 0x00000000 TV_V_CTL_7: 0x00000000 TV_SC_CTL_1: 0x00000000 TV_SC_CTL_2: 0x00000000 TV_SC_CTL_3: 0x00000000 TV_WIN_POS: 0x00000000 TV_WIN_SIZE: 0x00000000 TV_FILTER_CTL_1: 0x00000000 TV_FILTER_CTL_2: 0x00000000 TV_FILTER_CTL_3: 0x00000000 TV_CC_CONTROL: 0x00000000 TV_CC_DATA: 0x00000000 TV_H_LUMA_0: 0x00000000 TV_H_LUMA_59: 0x00000000 TV_H_CHROMA_0: 0x00000000 TV_H_CHROMA_59: 0x00000000 FBC_CFB_BASE: 0xffffffff FBC_LL_BASE: 0xffffffff FBC_CONTROL: 0xffffffff FBC_COMMAND: 0xffffffff FBC_STATUS: 0xffffffff FBC_CONTROL2: 0xffffffff FBC_FENCE_OFF: 0xffffffff FBC_MOD_NUM: 0xffffffff MI_MODE: 0x00000200 MI_ARB_STATE: 0x00000840 MI_RDRET_STATE: 0x00000000 ECOSKPD: 0x00000307 DP_B: 0x00000000 DPB_AUX_CH_CTL: 0x00000000 DPB_AUX_CH_DATA1: 0x00000000 DPB_AUX_CH_DATA2: 0x00000000 DPB_AUX_CH_DATA3: 0x00000000 DPB_AUX_CH_DATA4: 0x00000000 DPB_AUX_CH_DATA5: 0x00000000 DP_C: 0x00000000 DPC_AUX_CH_CTL: 0x00000000 DPC_AUX_CH_DATA1: 0x00000000 DPC_AUX_CH_DATA2: 0x00000000 DPC_AUX_CH_DATA3: 0x00000000 DPC_AUX_CH_DATA4: 0x00000000 DPC_AUX_CH_DATA5: 0x00000000 DP_D: 0x00000000 DPD_AUX_CH_CTL: 0x00000000 DPD_AUX_CH_DATA1: 0x00000000 DPD_AUX_CH_DATA2: 0x00000000 DPD_AUX_CH_DATA3: 0x00000000 DPD_AUX_CH_DATA4: 0x00000000 DPD_AUX_CH_DATA5: 0x00000000 AUD_CONFIG: 0x00000000 AUD_HDMIW_STATUS: 0x00000000 AUD_CONV_CHCNT: 0x00000000 VIDEO_DIP_CTL: 0x00000000 AUD_PINW_CNTR: 0x00000000 AUD_CNTL_ST: 0x00000000 AUD_PIN_CAP: 0x00000000 AUD_PINW_CAP: 0x00000000 AUD_PINW_UNSOLRESP: 0x00000000 AUD_OUT_DIG_CNVT: 0x00000000 AUD_OUT_CWCAP: 0x00000000 AUD_GRP_CAP: 0x00000000 FENCE 0: 0x00c00231 (enabled, X tiled, 4096 pitch, 0x00c00000 - 0x01000000 (4096kb)) FENCE 1: 0x01000231 (enabled, X tiled, 4096 pitch, 0x01000000 - 0x01400000 (4096kb)) FENCE 2: 0x01400231 (enabled, X tiled, 4096 pitch, 0x01400000 - 0x01800000 (4096kb)) FENCE 3: 0x00000000 (disabled) FENCE 4: 0x00000000 (disabled) FENCE 5: 0x00000000 (disabled) FENCE 6: 0x00000000 (disabled) FENCE 7: 0x00000000 (disabled) FENCE 8: 0x00000000 (disabled) FENCE 9: 0x00000000 (disabled) FENCE 10: 0x00000000 (disabled) FENCE 11: 0x00000000 (disabled) FENCE 12: 0x00000000 (disabled) FENCE 13: 0x00000000 (disabled) FENCE 14: 0x00000000 (disabled) FENCE 15: 0x00000000 (disabled) INST_PM: 0x00000000 pipe A dot 25173 n 5 m1 0 m2 116 p1 9 p2 10 pipe B dot 45000 n 4 m1 0 m2 103 p1 4 p2 14 Here's the diff between the two: [jcm@constitution ~]$ diff intel_regs_broken.txt intel_regs_works.txt 33c33 < LVDS: 0xc0308300 (enabled, pipe B, 18 bit, 1 channel) --- > LVDS: 0xc0300300 (enabled, pipe B, 18 bit, 1 channel) 95,97c95,97 < FPB0: 0x0020008c (n = 32, m1 = 0, m2 = 12) < FPB1: 0x0020008c (n = 32, m1 = 0, m2 = 12) < DPLL_B: 0x98020000 (enabled, non-dvo, default clock, LVDS mode, p1 = 3, p2 = 14, SDVO mult 1) --- > FPB0: 0x00100067 (n = 16, m1 = 0, m2 = 39) > FPB1: 0x00100067 (n = 16, m1 = 0, m2 = 39) > DPLL_B: 0x98040000 (enabled, non-dvo, default clock, LVDS mode, p1 = 4, p2 = 14, SDVO mult 1) 99,104c99,104 < HTOTAL_B: 0x053f03ff (1024 active, 1344 total) < HBLANK_B: 0x053f03ff (1024 start, 1344 end) < HSYNC_B: 0x049f0417 (1048 start, 1184 end) < VTOTAL_B: 0x03250257 (600 active, 806 total) < VBLANK_B: 0x02d102ab (684 start, 722 end) < VSYNC_B: 0x02c102bb (700 start, 706 end) --- > HTOTAL_B: 0x04af03ff (1024 active, 1200 total) > HBLANK_B: 0x04af03ff (1024 start, 1200 end) > HSYNC_B: 0x04570434 (1077 start, 1112 end) > VTOTAL_B: 0x02700257 (600 active, 625 total) > VBLANK_B: 0x02700257 (600 start, 625 end) > VSYNC_B: 0x0260025b (604 start, 609 end) 192c192 < FENCE 2: 0x00000000 (disabled) --- > FENCE 2: 0x01400231 (enabled, X tiled, 4096 pitch, 0x01400000 - 0x01800000 (4096kb)) 208c208 < pipe B dot 64914 n 5 m1 0 m2 140 p1 3 p2 14 --- > pipe B dot 45000 n 4 m1 0 m2 103 p1 4 p2 14 Jon. ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [bisected] offset display bug in i915 @ 2010-11-08 23:08 ` Jon Masters 0 siblings, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-08 23:08 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Linux Kernel Mailing List On Mon, 2010-11-08 at 12:13 +0000, Chris Wilson wrote: > On Mon, 08 Nov 2010 06:29:09 -0500, Jon Masters <jonathan@jonmasters.org> 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? > > 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 { I tried this, which didn't work. Then I added this (ignore stupid evolution formatting - convenient for email backlog, but not mutt): diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index 17bcb7d..a0bb443 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -462,6 +462,14 @@ intel_lvds_detect(struct drm_connector *connector, bool force) { struct drm_device *dev = connector->dev; enum drm_connector_status status = connector_status_connected; + /* JCM - added this */ + struct drm_i915_private *dev_priv = dev->dev_private; + u8 pin = GMBUS_PORT_PANEL; + struct edid *edid = drm_get_edid(connector, &dev_priv->gmbus[pin].adapter); + + /* I was asked to free in here */ + if (edid) + kfree(edid); /* ACPI lid methods were generally unreliable in this generation, so * don't even bother. Which should have made the edid always get freed on detect. That didn't work either. I might wind up learning something about the DRM stack. Anyway. Here's the reg dumper output. First, for a busticated kernel: [jcm@constitution ~]$ cat intel_regs_broken.txt DCC: 0x00200020 (single channel, XOR randomization: enabled, XOR bit: 11) CHDECMISC: 0x42000064 (XOR bank, ch2 enh disabled, ch1 enh disabled, ch0 enh enabled, flex disabled, ep not present) C0DRB0: 0x00200020 (0x0020) C0DRB1: 0x00200020 (0x0020) C0DRB2: 0x00200020 (0x0020) C0DRB3: 0x00880020 (0x0020) C1DRB0: 0x00000000 (0x0000) C1DRB1: 0x00000000 (0x0000) C1DRB2: 0x00000000 (0x0000) C1DRB3: 0x00000000 (0x0000) C0DRA01: 0x00000088 (0x0088) C0DRA23: 0x00000000 (0x0000) C1DRA01: 0x00000000 (0x0000) C1DRA23: 0x00000000 (0x0000) PGETBL_CTL: 0x00000001 VCLK_DIVISOR_VGA0: 0x00200074 (n = 32, m1 = 0, m2 = 52) VCLK_DIVISOR_VGA1: 0x00200074 (n = 32, m1 = 0, m2 = 52) VCLK_POST_DIV: 0x00800100 (vga0 p1 = 2, p2 = 2, vga1 p1 = 3, p2 = 2) DPLL_TEST: 0x00010001 () CACHE_MODE_0: 0x00006820 D_STATE: 0x0000000b DSPCLK_GATE_D: 0x00000000 (clock gates disabled:) RENCLK_GATE_D1: 0x00000000 RENCLK_GATE_D2: 0x00000000 SDVOB: 0x00300000 (disabled, pipe A, stall disabled, not detected) SDVOC: 0x00300000 (disabled, pipe A, stall disabled, not detected) SDVOUDI: 0x00000000 DSPARB: 0x00001d9c DSPFW1: 0xf1830f0f DSPFW2: 0x0000030f DSPFW3: 0x6700018f ADPA: 0x40008c18 (disabled, pipe B, +hsync, +vsync) LVDS: 0xc0308300 (enabled, pipe B, 18 bit, 1 channel) DVOA: 0x00000000 (disabled, pipe A, no stall, -hsync, -vsync) DVOB: 0x00300000 (disabled, pipe A, no stall, -hsync, -vsync) DVOC: 0x00300000 (disabled, pipe A, no stall, -hsync, -vsync) DVOA_SRCDIM: 0x00000000 DVOB_SRCDIM: 0x00000000 DVOC_SRCDIM: 0x00000000 PP_CONTROL: 0x00000001 (power target: on) PP_STATUS: 0xc0000008 (on, ready, sequencing idle) PP_ON_DELAYS: 0x025807d0 PP_OFF_DELAYS: 0x01f407d0 PP_DIVISOR: 0x00209d05 PFIT_CONTROL: 0x00000008 PFIT_PGM_RATIOS: 0x00000000 PORT_HOTPLUG_EN: 0x00000220 PORT_HOTPLUG_STAT: 0x00001000 DSPACNTR: 0xd9000000 (enabled, pipe B) DSPASTRIDE: 0x00001000 (4096 bytes) DSPAPOS: 0x00000000 (0, 0) DSPASIZE: 0x025703ff (1024, 600) DSPABASE: 0x00830000 DSPASURF: 0x00000000 DSPATILEOFF: 0x00000000 PIPEACONF: 0x00000000 (disabled, single-wide) PIPEASRC: 0x027f01df (640, 480) PIPEASTAT: 0x00000000 (status:) PIPEA_GMCH_DATA_M: 0x00000000 PIPEA_GMCH_DATA_N: 0x00000000 PIPEA_DP_LINK_M: 0x00000000 PIPEA_DP_LINK_N: 0x00000000 CURSOR_A_BASE: 0x00000000 CURSOR_A_CONTROL: 0x00000000 CURSOR_A_POSITION: 0x00000000 FPA0: 0x00200074 (n = 32, m1 = 0, m2 = 52) FPA1: 0x00200074 (n = 32, m1 = 0, m2 = 52) DPLL_A: 0x04800000 (disabled, non-dvo, VGA, default clock, DAC/serial mode, p1 = 9, p2 = 10, SDVO mult 1) DPLL_A_MD: 0x00000000 HTOTAL_A: 0x031f027f (640 active, 800 total) HBLANK_A: 0x03170287 (648 start, 792 end) HSYNC_A: 0x02ef028f (656 start, 752 end) VTOTAL_A: 0x020c01df (480 active, 525 total) VBLANK_A: 0x020401e7 (488 start, 517 end) VSYNC_A: 0x01eb01e9 (490 start, 492 end) BCLRPAT_A: 0x00000000 VSYNCSHIFT_A: 0x00000000 DSPBCNTR: 0x49000000 (disabled, pipe B) DSPBSTRIDE: 0x00000280 (640 bytes) DSPBPOS: 0x00000000 (0, 0) DSPBSIZE: 0x018f02cf (720, 400) DSPBBASE: 0x00000000 DSPBSURF: 0x00000000 DSPBTILEOFF: 0x00000000 PIPEBCONF: 0x80000000 (enabled, single-wide) PIPEBSRC: 0x03ff0257 (1024, 600) PIPEBSTAT: 0x00400202 (status: LBLC_EVENT_ENABLE VSYNC_INT_STATUS VBLANK_INT_STATUS) PIPEB_GMCH_DATA_M: 0x00000000 PIPEB_GMCH_DATA_N: 0x00000000 PIPEB_DP_LINK_M: 0x00000000 PIPEB_DP_LINK_N: 0x00000000 CURSOR_B_BASE: 0x00000000 CURSOR_B_CONTROL: 0x10000000 CURSOR_B_POSITION: 0x012801f9 FPB0: 0x0020008c (n = 32, m1 = 0, m2 = 12) FPB1: 0x0020008c (n = 32, m1 = 0, m2 = 12) DPLL_B: 0x98020000 (enabled, non-dvo, default clock, LVDS mode, p1 = 3, p2 = 14, SDVO mult 1) DPLL_B_MD: 0x00000000 HTOTAL_B: 0x053f03ff (1024 active, 1344 total) HBLANK_B: 0x053f03ff (1024 start, 1344 end) HSYNC_B: 0x049f0417 (1048 start, 1184 end) VTOTAL_B: 0x03250257 (600 active, 806 total) VBLANK_B: 0x02d102ab (684 start, 722 end) VSYNC_B: 0x02c102bb (700 start, 706 end) BCLRPAT_B: 0x00000000 VSYNCSHIFT_B: 0x00000000 VCLK_DIVISOR_VGA0: 0x00200074 VCLK_DIVISOR_VGA1: 0x00200074 VCLK_POST_DIV: 0x00800100 VGACNTRL: 0x80000000 (disabled) TV_CTL: 0x00000000 TV_DAC: 0x00000000 TV_CSC_Y: 0x00000000 TV_CSC_Y2: 0x00000000 TV_CSC_U: 0x00000000 TV_CSC_U2: 0x00000000 TV_CSC_V: 0x00000000 TV_CSC_V2: 0x00000000 TV_CLR_KNOBS: 0x00000000 TV_CLR_LEVEL: 0x00000000 TV_H_CTL_1: 0x00000000 TV_H_CTL_2: 0x00000000 TV_H_CTL_3: 0x00000000 TV_V_CTL_1: 0x00000000 TV_V_CTL_2: 0x00000000 TV_V_CTL_3: 0x00000000 TV_V_CTL_4: 0x00000000 TV_V_CTL_5: 0x00000000 TV_V_CTL_6: 0x00000000 TV_V_CTL_7: 0x00000000 TV_SC_CTL_1: 0x00000000 TV_SC_CTL_2: 0x00000000 TV_SC_CTL_3: 0x00000000 TV_WIN_POS: 0x00000000 TV_WIN_SIZE: 0x00000000 TV_FILTER_CTL_1: 0x00000000 TV_FILTER_CTL_2: 0x00000000 TV_FILTER_CTL_3: 0x00000000 TV_CC_CONTROL: 0x00000000 TV_CC_DATA: 0x00000000 TV_H_LUMA_0: 0x00000000 TV_H_LUMA_59: 0x00000000 TV_H_CHROMA_0: 0x00000000 TV_H_CHROMA_59: 0x00000000 FBC_CFB_BASE: 0xffffffff FBC_LL_BASE: 0xffffffff FBC_CONTROL: 0xffffffff FBC_COMMAND: 0xffffffff FBC_STATUS: 0xffffffff FBC_CONTROL2: 0xffffffff FBC_FENCE_OFF: 0xffffffff FBC_MOD_NUM: 0xffffffff MI_MODE: 0x00000200 MI_ARB_STATE: 0x00000840 MI_RDRET_STATE: 0x00000000 ECOSKPD: 0x00000307 DP_B: 0x00000000 DPB_AUX_CH_CTL: 0x00000000 DPB_AUX_CH_DATA1: 0x00000000 DPB_AUX_CH_DATA2: 0x00000000 DPB_AUX_CH_DATA3: 0x00000000 DPB_AUX_CH_DATA4: 0x00000000 DPB_AUX_CH_DATA5: 0x00000000 DP_C: 0x00000000 DPC_AUX_CH_CTL: 0x00000000 DPC_AUX_CH_DATA1: 0x00000000 DPC_AUX_CH_DATA2: 0x00000000 DPC_AUX_CH_DATA3: 0x00000000 DPC_AUX_CH_DATA4: 0x00000000 DPC_AUX_CH_DATA5: 0x00000000 DP_D: 0x00000000 DPD_AUX_CH_CTL: 0x00000000 DPD_AUX_CH_DATA1: 0x00000000 DPD_AUX_CH_DATA2: 0x00000000 DPD_AUX_CH_DATA3: 0x00000000 DPD_AUX_CH_DATA4: 0x00000000 DPD_AUX_CH_DATA5: 0x00000000 AUD_CONFIG: 0x00000000 AUD_HDMIW_STATUS: 0x00000000 AUD_CONV_CHCNT: 0x00000000 VIDEO_DIP_CTL: 0x00000000 AUD_PINW_CNTR: 0x00000000 AUD_CNTL_ST: 0x00000000 AUD_PIN_CAP: 0x00000000 AUD_PINW_CAP: 0x00000000 AUD_PINW_UNSOLRESP: 0x00000000 AUD_OUT_DIG_CNVT: 0x00000000 AUD_OUT_CWCAP: 0x00000000 AUD_GRP_CAP: 0x00000000 FENCE 0: 0x00c00231 (enabled, X tiled, 4096 pitch, 0x00c00000 - 0x01000000 (4096kb)) FENCE 1: 0x01000231 (enabled, X tiled, 4096 pitch, 0x01000000 - 0x01400000 (4096kb)) FENCE 2: 0x00000000 (disabled) FENCE 3: 0x00000000 (disabled) FENCE 4: 0x00000000 (disabled) FENCE 5: 0x00000000 (disabled) FENCE 6: 0x00000000 (disabled) FENCE 7: 0x00000000 (disabled) FENCE 8: 0x00000000 (disabled) FENCE 9: 0x00000000 (disabled) FENCE 10: 0x00000000 (disabled) FENCE 11: 0x00000000 (disabled) FENCE 12: 0x00000000 (disabled) FENCE 13: 0x00000000 (disabled) FENCE 14: 0x00000000 (disabled) FENCE 15: 0x00000000 (disabled) INST_PM: 0x00000000 pipe A dot 25173 n 5 m1 0 m2 116 p1 9 p2 10 pipe B dot 64914 n 5 m1 0 m2 140 p1 3 p2 14 And here for a non-busticated kernel: [jcm@constitution ~]$ cat intel_regs_works.txt DCC: 0x00200020 (single channel, XOR randomization: enabled, XOR bit: 11) CHDECMISC: 0x42000064 (XOR bank, ch2 enh disabled, ch1 enh disabled, ch0 enh enabled, flex disabled, ep not present) C0DRB0: 0x00200020 (0x0020) C0DRB1: 0x00200020 (0x0020) C0DRB2: 0x00200020 (0x0020) C0DRB3: 0x00880020 (0x0020) C1DRB0: 0x00000000 (0x0000) C1DRB1: 0x00000000 (0x0000) C1DRB2: 0x00000000 (0x0000) C1DRB3: 0x00000000 (0x0000) C0DRA01: 0x00000088 (0x0088) C0DRA23: 0x00000000 (0x0000) C1DRA01: 0x00000000 (0x0000) C1DRA23: 0x00000000 (0x0000) PGETBL_CTL: 0x00000001 VCLK_DIVISOR_VGA0: 0x00200074 (n = 32, m1 = 0, m2 = 52) VCLK_DIVISOR_VGA1: 0x00200074 (n = 32, m1 = 0, m2 = 52) VCLK_POST_DIV: 0x00800100 (vga0 p1 = 2, p2 = 2, vga1 p1 = 3, p2 = 2) DPLL_TEST: 0x00010001 () CACHE_MODE_0: 0x00006820 D_STATE: 0x0000000b DSPCLK_GATE_D: 0x00000000 (clock gates disabled:) RENCLK_GATE_D1: 0x00000000 RENCLK_GATE_D2: 0x00000000 SDVOB: 0x00300000 (disabled, pipe A, stall disabled, not detected) SDVOC: 0x00300000 (disabled, pipe A, stall disabled, not detected) SDVOUDI: 0x00000000 DSPARB: 0x00001d9c DSPFW1: 0xf1830f0f DSPFW2: 0x0000030f DSPFW3: 0x6700018f ADPA: 0x40008c18 (disabled, pipe B, +hsync, +vsync) LVDS: 0xc0300300 (enabled, pipe B, 18 bit, 1 channel) DVOA: 0x00000000 (disabled, pipe A, no stall, -hsync, -vsync) DVOB: 0x00300000 (disabled, pipe A, no stall, -hsync, -vsync) DVOC: 0x00300000 (disabled, pipe A, no stall, -hsync, -vsync) DVOA_SRCDIM: 0x00000000 DVOB_SRCDIM: 0x00000000 DVOC_SRCDIM: 0x00000000 PP_CONTROL: 0x00000001 (power target: on) PP_STATUS: 0xc0000008 (on, ready, sequencing idle) PP_ON_DELAYS: 0x025807d0 PP_OFF_DELAYS: 0x01f407d0 PP_DIVISOR: 0x00209d05 PFIT_CONTROL: 0x00000008 PFIT_PGM_RATIOS: 0x00000000 PORT_HOTPLUG_EN: 0x00000220 PORT_HOTPLUG_STAT: 0x00001000 DSPACNTR: 0xd9000000 (enabled, pipe B) DSPASTRIDE: 0x00001000 (4096 bytes) DSPAPOS: 0x00000000 (0, 0) DSPASIZE: 0x025703ff (1024, 600) DSPABASE: 0x00830000 DSPASURF: 0x00000000 DSPATILEOFF: 0x00000000 PIPEACONF: 0x00000000 (disabled, single-wide) PIPEASRC: 0x027f01df (640, 480) PIPEASTAT: 0x00000000 (status:) PIPEA_GMCH_DATA_M: 0x00000000 PIPEA_GMCH_DATA_N: 0x00000000 PIPEA_DP_LINK_M: 0x00000000 PIPEA_DP_LINK_N: 0x00000000 CURSOR_A_BASE: 0x00000000 CURSOR_A_CONTROL: 0x00000000 CURSOR_A_POSITION: 0x00000000 FPA0: 0x00200074 (n = 32, m1 = 0, m2 = 52) FPA1: 0x00200074 (n = 32, m1 = 0, m2 = 52) DPLL_A: 0x04800000 (disabled, non-dvo, VGA, default clock, DAC/serial mode, p1 = 9, p2 = 10, SDVO mult 1) DPLL_A_MD: 0x00000000 HTOTAL_A: 0x031f027f (640 active, 800 total) HBLANK_A: 0x03170287 (648 start, 792 end) HSYNC_A: 0x02ef028f (656 start, 752 end) VTOTAL_A: 0x020c01df (480 active, 525 total) VBLANK_A: 0x020401e7 (488 start, 517 end) VSYNC_A: 0x01eb01e9 (490 start, 492 end) BCLRPAT_A: 0x00000000 VSYNCSHIFT_A: 0x00000000 DSPBCNTR: 0x49000000 (disabled, pipe B) DSPBSTRIDE: 0x00000280 (640 bytes) DSPBPOS: 0x00000000 (0, 0) DSPBSIZE: 0x018f02cf (720, 400) DSPBBASE: 0x00000000 DSPBSURF: 0x00000000 DSPBTILEOFF: 0x00000000 PIPEBCONF: 0x80000000 (enabled, single-wide) PIPEBSRC: 0x03ff0257 (1024, 600) PIPEBSTAT: 0x00400202 (status: LBLC_EVENT_ENABLE VSYNC_INT_STATUS VBLANK_INT_STATUS) PIPEB_GMCH_DATA_M: 0x00000000 PIPEB_GMCH_DATA_N: 0x00000000 PIPEB_DP_LINK_M: 0x00000000 PIPEB_DP_LINK_N: 0x00000000 CURSOR_B_BASE: 0x00000000 CURSOR_B_CONTROL: 0x10000000 CURSOR_B_POSITION: 0x012801f9 FPB0: 0x00100067 (n = 16, m1 = 0, m2 = 39) FPB1: 0x00100067 (n = 16, m1 = 0, m2 = 39) DPLL_B: 0x98040000 (enabled, non-dvo, default clock, LVDS mode, p1 = 4, p2 = 14, SDVO mult 1) DPLL_B_MD: 0x00000000 HTOTAL_B: 0x04af03ff (1024 active, 1200 total) HBLANK_B: 0x04af03ff (1024 start, 1200 end) HSYNC_B: 0x04570434 (1077 start, 1112 end) VTOTAL_B: 0x02700257 (600 active, 625 total) VBLANK_B: 0x02700257 (600 start, 625 end) VSYNC_B: 0x0260025b (604 start, 609 end) BCLRPAT_B: 0x00000000 VSYNCSHIFT_B: 0x00000000 VCLK_DIVISOR_VGA0: 0x00200074 VCLK_DIVISOR_VGA1: 0x00200074 VCLK_POST_DIV: 0x00800100 VGACNTRL: 0x80000000 (disabled) TV_CTL: 0x00000000 TV_DAC: 0x00000000 TV_CSC_Y: 0x00000000 TV_CSC_Y2: 0x00000000 TV_CSC_U: 0x00000000 TV_CSC_U2: 0x00000000 TV_CSC_V: 0x00000000 TV_CSC_V2: 0x00000000 TV_CLR_KNOBS: 0x00000000 TV_CLR_LEVEL: 0x00000000 TV_H_CTL_1: 0x00000000 TV_H_CTL_2: 0x00000000 TV_H_CTL_3: 0x00000000 TV_V_CTL_1: 0x00000000 TV_V_CTL_2: 0x00000000 TV_V_CTL_3: 0x00000000 TV_V_CTL_4: 0x00000000 TV_V_CTL_5: 0x00000000 TV_V_CTL_6: 0x00000000 TV_V_CTL_7: 0x00000000 TV_SC_CTL_1: 0x00000000 TV_SC_CTL_2: 0x00000000 TV_SC_CTL_3: 0x00000000 TV_WIN_POS: 0x00000000 TV_WIN_SIZE: 0x00000000 TV_FILTER_CTL_1: 0x00000000 TV_FILTER_CTL_2: 0x00000000 TV_FILTER_CTL_3: 0x00000000 TV_CC_CONTROL: 0x00000000 TV_CC_DATA: 0x00000000 TV_H_LUMA_0: 0x00000000 TV_H_LUMA_59: 0x00000000 TV_H_CHROMA_0: 0x00000000 TV_H_CHROMA_59: 0x00000000 FBC_CFB_BASE: 0xffffffff FBC_LL_BASE: 0xffffffff FBC_CONTROL: 0xffffffff FBC_COMMAND: 0xffffffff FBC_STATUS: 0xffffffff FBC_CONTROL2: 0xffffffff FBC_FENCE_OFF: 0xffffffff FBC_MOD_NUM: 0xffffffff MI_MODE: 0x00000200 MI_ARB_STATE: 0x00000840 MI_RDRET_STATE: 0x00000000 ECOSKPD: 0x00000307 DP_B: 0x00000000 DPB_AUX_CH_CTL: 0x00000000 DPB_AUX_CH_DATA1: 0x00000000 DPB_AUX_CH_DATA2: 0x00000000 DPB_AUX_CH_DATA3: 0x00000000 DPB_AUX_CH_DATA4: 0x00000000 DPB_AUX_CH_DATA5: 0x00000000 DP_C: 0x00000000 DPC_AUX_CH_CTL: 0x00000000 DPC_AUX_CH_DATA1: 0x00000000 DPC_AUX_CH_DATA2: 0x00000000 DPC_AUX_CH_DATA3: 0x00000000 DPC_AUX_CH_DATA4: 0x00000000 DPC_AUX_CH_DATA5: 0x00000000 DP_D: 0x00000000 DPD_AUX_CH_CTL: 0x00000000 DPD_AUX_CH_DATA1: 0x00000000 DPD_AUX_CH_DATA2: 0x00000000 DPD_AUX_CH_DATA3: 0x00000000 DPD_AUX_CH_DATA4: 0x00000000 DPD_AUX_CH_DATA5: 0x00000000 AUD_CONFIG: 0x00000000 AUD_HDMIW_STATUS: 0x00000000 AUD_CONV_CHCNT: 0x00000000 VIDEO_DIP_CTL: 0x00000000 AUD_PINW_CNTR: 0x00000000 AUD_CNTL_ST: 0x00000000 AUD_PIN_CAP: 0x00000000 AUD_PINW_CAP: 0x00000000 AUD_PINW_UNSOLRESP: 0x00000000 AUD_OUT_DIG_CNVT: 0x00000000 AUD_OUT_CWCAP: 0x00000000 AUD_GRP_CAP: 0x00000000 FENCE 0: 0x00c00231 (enabled, X tiled, 4096 pitch, 0x00c00000 - 0x01000000 (4096kb)) FENCE 1: 0x01000231 (enabled, X tiled, 4096 pitch, 0x01000000 - 0x01400000 (4096kb)) FENCE 2: 0x01400231 (enabled, X tiled, 4096 pitch, 0x01400000 - 0x01800000 (4096kb)) FENCE 3: 0x00000000 (disabled) FENCE 4: 0x00000000 (disabled) FENCE 5: 0x00000000 (disabled) FENCE 6: 0x00000000 (disabled) FENCE 7: 0x00000000 (disabled) FENCE 8: 0x00000000 (disabled) FENCE 9: 0x00000000 (disabled) FENCE 10: 0x00000000 (disabled) FENCE 11: 0x00000000 (disabled) FENCE 12: 0x00000000 (disabled) FENCE 13: 0x00000000 (disabled) FENCE 14: 0x00000000 (disabled) FENCE 15: 0x00000000 (disabled) INST_PM: 0x00000000 pipe A dot 25173 n 5 m1 0 m2 116 p1 9 p2 10 pipe B dot 45000 n 4 m1 0 m2 103 p1 4 p2 14 Here's the diff between the two: [jcm@constitution ~]$ diff intel_regs_broken.txt intel_regs_works.txt 33c33 < LVDS: 0xc0308300 (enabled, pipe B, 18 bit, 1 channel) --- > LVDS: 0xc0300300 (enabled, pipe B, 18 bit, 1 channel) 95,97c95,97 < FPB0: 0x0020008c (n = 32, m1 = 0, m2 = 12) < FPB1: 0x0020008c (n = 32, m1 = 0, m2 = 12) < DPLL_B: 0x98020000 (enabled, non-dvo, default clock, LVDS mode, p1 = 3, p2 = 14, SDVO mult 1) --- > FPB0: 0x00100067 (n = 16, m1 = 0, m2 = 39) > FPB1: 0x00100067 (n = 16, m1 = 0, m2 = 39) > DPLL_B: 0x98040000 (enabled, non-dvo, default clock, LVDS mode, p1 = 4, p2 = 14, SDVO mult 1) 99,104c99,104 < HTOTAL_B: 0x053f03ff (1024 active, 1344 total) < HBLANK_B: 0x053f03ff (1024 start, 1344 end) < HSYNC_B: 0x049f0417 (1048 start, 1184 end) < VTOTAL_B: 0x03250257 (600 active, 806 total) < VBLANK_B: 0x02d102ab (684 start, 722 end) < VSYNC_B: 0x02c102bb (700 start, 706 end) --- > HTOTAL_B: 0x04af03ff (1024 active, 1200 total) > HBLANK_B: 0x04af03ff (1024 start, 1200 end) > HSYNC_B: 0x04570434 (1077 start, 1112 end) > VTOTAL_B: 0x02700257 (600 active, 625 total) > VBLANK_B: 0x02700257 (600 start, 625 end) > VSYNC_B: 0x0260025b (604 start, 609 end) 192c192 < FENCE 2: 0x00000000 (disabled) --- > FENCE 2: 0x01400231 (enabled, X tiled, 4096 pitch, 0x01400000 - 0x01800000 (4096kb)) 208c208 < pipe B dot 64914 n 5 m1 0 m2 140 p1 3 p2 14 --- > pipe B dot 45000 n 4 m1 0 m2 103 p1 4 p2 14 Jon. ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [OT] avoid preformatting in Evolution (was: [bisected] offset display bug in i915) 2010-11-08 23:08 ` Jon Masters (?) @ 2010-11-08 23:23 ` Paul Menzel -1 siblings, 0 replies; 27+ messages in thread From: Paul Menzel @ 2010-11-08 23:23 UTC (permalink / raw) To: intel-gfx [-- Attachment #1.1: Type: text/plain, Size: 435 bytes --] Am Montag, den 08.11.2010, 18:08 -0500 schrieb Jon Masters: […] > I tried this, which didn't work. Then I added this (ignore stupid > evolution formatting - convenient for email backlog, but not mutt): You can select the corresponding sections and choose preformatted over normal in the list right below the subject line to avoid automatic line breaks after a certain amount of characters. […] Thanks, Paul [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH] drm/i915: Fix LVDS fixed-mode regression from 219adae1 2010-11-08 23:08 ` Jon Masters (?) (?) @ 2010-11-08 23:24 ` Chris Wilson 2010-11-09 0:16 ` Jon Masters 2010-11-11 8:39 ` Jon Masters -1 siblings, 2 replies; 27+ messages in thread From: Chris Wilson @ 2010-11-08 23:24 UTC (permalink / raw) To: Jon Masters; +Cc: linux-kernel, Chris Wilson Commit 219adae1 cached the EDID found during LVDS init, but in the process prevented the init routine from discovering the preferred fixed-mode for the panel. This was causing us to guess the correct mode, which sometimes is wide of the mark. Reported-by: Jon Masters <jonathan@jonmasters.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> --- drivers/gpu/drm/i915/intel_lvds.c | 16 +++++++++++----- 1 files changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index f1a6499..4324a32 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -481,11 +481,8 @@ static int intel_lvds_get_modes(struct drm_connector *connector) struct drm_device *dev = connector->dev; struct drm_display_mode *mode; - if (intel_lvds->edid) { - drm_mode_connector_update_edid_property(connector, - intel_lvds->edid); + if (intel_lvds->edid) return drm_add_edid_modes(connector, intel_lvds->edid); - } mode = drm_mode_duplicate(dev, intel_lvds->fixed_mode); if (mode == 0) @@ -939,7 +936,16 @@ 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 (drm_add_edid_modes(connector, + intel_lvds->edid)) { + drm_mode_connector_update_edid_property(connector, + intel_lvds->edid); + } else { + kfree(intel_lvds->edid); + intel_lvds->edid = NULL; + } + } if (!intel_lvds->edid) { /* Didn't get an EDID, so * Set wide sync ranges so we get all modes -- 1.7.2.3 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH] drm/i915: Fix LVDS fixed-mode regression from 219adae1 2010-11-08 23:24 ` [PATCH] drm/i915: Fix LVDS fixed-mode regression from 219adae1 Chris Wilson @ 2010-11-09 0:16 ` Jon Masters 2010-11-11 8:39 ` Jon Masters 1 sibling, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-09 0:16 UTC (permalink / raw) To: Chris Wilson; +Cc: linux-kernel On Mon, 2010-11-08 at 23:24 +0000, Chris Wilson wrote: > Commit 219adae1 cached the EDID found during LVDS init, but in the > process prevented the init routine from discovering the preferred > fixed-mode for the panel. This was causing us to guess the correct mode, > which sometimes is wide of the mark. > > Reported-by: Jon Masters <jonathan@jonmasters.org> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> I have tested this patch, and my LVDS panel display on this Eee PC 1015PEM is now working correctly :) Obviously I suspect others will be affected in due course, so hopefully this can make the next 2.6.37 RC. Please add my: Tested-by: Jon Masters <jonathan@jonmasters.org> To this patch also. Jon. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] drm/i915: Fix LVDS fixed-mode regression from 219adae1 2010-11-08 23:24 ` [PATCH] drm/i915: Fix LVDS fixed-mode regression from 219adae1 Chris Wilson 2010-11-09 0:16 ` Jon Masters @ 2010-11-11 8:39 ` Jon Masters 1 sibling, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-11 8:39 UTC (permalink / raw) To: Chris Wilson; +Cc: linux-kernel On Mon, 2010-11-08 at 23:24 +0000, Chris Wilson wrote: > Commit 219adae1 cached the EDID found during LVDS init, but in the > process prevented the init routine from discovering the preferred > fixed-mode for the panel. This was causing us to guess the correct mode, > which sometimes is wide of the mark. > > Reported-by: Jon Masters <jonathan@jonmasters.org> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> This is now being tracked at the following k.o BZ: https://bugzilla.kernel.org/show_bug.cgi?id=22712 Please mark the BZ when you push the patch. Thanks. Jon. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [bisected] offset display bug in i915 2010-11-08 10:54 ` Jon Masters 2010-11-08 11:22 ` Jon Masters @ 2010-11-08 11:33 ` James Courtier-Dutton 2010-11-08 11:38 ` Jon Masters 1 sibling, 1 reply; 27+ messages in thread From: James Courtier-Dutton @ 2010-11-08 11:33 UTC (permalink / raw) To: Jon Masters; +Cc: Chris Wilson, intel-gfx, Linux Kernel Mailing List On 8 November 2010 10:54, Jon Masters <jonathan@jonmasters.org> 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 > hexdump -C is a little easier to read and compare with other hexdumps. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [bisected] offset display bug in i915 2010-11-08 11:33 ` [bisected] offset display bug in i915 James Courtier-Dutton @ 2010-11-08 11:38 ` Jon Masters 0 siblings, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-08 11:38 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: Chris Wilson, intel-gfx, Linux Kernel Mailing List On Mon, 2010-11-08 at 11:33 +0000, James Courtier-Dutton wrote: > On 8 November 2010 10:54, Jon Masters <jonathan@jonmasters.org> 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 > > > hexdump -C is a little easier to read and compare with other hexdumps. Yea, but I already ran edid-decode for Chris. Chris: I suggest your idea of hacking up edid-decode to also take hexdumps is a good idea for the future. That way you can feed it the output from xrandr, or from people who like me don't realize that it's preferred to post the interpreted output. Jon. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [bisected] offset display bug in i915 @ 2010-11-08 11:38 ` Jon Masters 0 siblings, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-08 11:38 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: intel-gfx, Linux Kernel Mailing List On Mon, 2010-11-08 at 11:33 +0000, James Courtier-Dutton wrote: > On 8 November 2010 10:54, Jon Masters <jonathan@jonmasters.org> 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 > > > hexdump -C is a little easier to read and compare with other hexdumps. Yea, but I already ran edid-decode for Chris. Chris: I suggest your idea of hacking up edid-decode to also take hexdumps is a good idea for the future. That way you can feed it the output from xrandr, or from people who like me don't realize that it's preferred to post the interpreted output. Jon. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [bisected] offset display bug in i915 2010-11-08 10:27 ` Chris Wilson 2010-11-08 10:54 ` Jon Masters @ 2010-11-08 11:26 ` James Courtier-Dutton 2010-11-08 11:34 ` Jon Masters 1 sibling, 1 reply; 27+ messages in thread From: James Courtier-Dutton @ 2010-11-08 11:26 UTC (permalink / raw) To: Chris Wilson; +Cc: Jon Masters, intel-gfx, Linux Kernel Mailing List On 8 November 2010 10:27, Chris Wilson <chris@chris-wilson.co.uk> wrote: > On Mon, 08 Nov 2010 05:18:32 -0500, Jon Masters <jonathan@jonmasters.org> wrote: >> Hi Chris, >> >> The following patch that you recently committed breaks my ASUS Eee PC >> 1015PEM by causing the display to be offset by about 1 inch (a few >> centimeters) when the mode is (re)set during boot. I previously posted >> both photographs and video of the problem in another "PROBLEM" thread. > > [snip] > >> I'll look at the patch. Either the EDID is *not* consistent (in which >> case, why are we not seeing other bugs like this?) or there is something >> specific to this system or panel used. > > Interesting. Or even downright bizarre! Can you disable the caching > (hopefully the patch is still revertible) and save the EDID > (/sys/class/drm/card0-LVDS-1/edid) periodically? Might be simplest just to > dump the EDID every time we probe the LVDS if it has changed. > -Chris > Hi, I have observed major corruption issues for kernel 2.6.37. Going back to 2.6.36 stable restores things to normality. I unfortunately do not have time to track down the problem, but I thought I would mention it as it could be causing your problem. My problems were: Corrupting the library cache so that .so files failed to load any more. Corrupting .o files during compilation so that the linker did not even recognize them as .o files. Corrupted data between a DVB card and the recording on the HD. I am just mentioning it, because the cause might in fact be somewhere else. Kind Regards James ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [bisected] offset display bug in i915 2010-11-08 11:26 ` James Courtier-Dutton @ 2010-11-08 11:34 ` Jon Masters 0 siblings, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-08 11:34 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: Chris Wilson, intel-gfx, Linux Kernel Mailing List On Mon, 2010-11-08 at 11:26 +0000, James Courtier-Dutton wrote: > On 8 November 2010 10:27, Chris Wilson <chris@chris-wilson.co.uk> wrote: > > On Mon, 08 Nov 2010 05:18:32 -0500, Jon Masters <jonathan@jonmasters.org> wrote: > >> Hi Chris, > >> > >> The following patch that you recently committed breaks my ASUS Eee PC > >> 1015PEM by causing the display to be offset by about 1 inch (a few > >> centimeters) when the mode is (re)set during boot. I previously posted > >> both photographs and video of the problem in another "PROBLEM" thread. > > > > [snip] > > > >> I'll look at the patch. Either the EDID is *not* consistent (in which > >> case, why are we not seeing other bugs like this?) or there is something > >> specific to this system or panel used. > > > > Interesting. Or even downright bizarre! Can you disable the caching > > (hopefully the patch is still revertible) and save the EDID > > (/sys/class/drm/card0-LVDS-1/edid) periodically? Might be simplest just to > > dump the EDID every time we probe the LVDS if it has changed. > I have observed major corruption issues for kernel 2.6.37. Sad to hear, but none of what you are describing is related to this bug. This bug has to do specifically with a small patch that added cacheing of EDID panel data under the assumption that it wouldn't change. It only affects your display, not linker, library objects, file systems, or in fact anything other than getting geometry and location on screen right. > Going back to 2.6.36 stable restores things to normality. > I unfortunately do not have time to track down the problem, but I > thought I would mention it as it could be causing your problem. > My problems were: > Corrupting the library cache so that .so files failed to load any more. > Corrupting .o files during compilation so that the linker did not even > recognize them as .o files. > Corrupted data between a DVB card and the recording on the HD. > I am just mentioning it, because the cause might in fact be somewhere else. You might have a bad compiler, be switching distro packages, who knows. Perhaps you can file a detailed bug report explaining your problems on the bugzilla.kernel.org, or followup with more detail (to a new thread). Jon. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [bisected] offset display bug in i915 @ 2010-11-08 11:34 ` Jon Masters 0 siblings, 0 replies; 27+ messages in thread From: Jon Masters @ 2010-11-08 11:34 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: intel-gfx, Linux Kernel Mailing List On Mon, 2010-11-08 at 11:26 +0000, James Courtier-Dutton wrote: > On 8 November 2010 10:27, Chris Wilson <chris@chris-wilson.co.uk> wrote: > > On Mon, 08 Nov 2010 05:18:32 -0500, Jon Masters <jonathan@jonmasters.org> wrote: > >> Hi Chris, > >> > >> The following patch that you recently committed breaks my ASUS Eee PC > >> 1015PEM by causing the display to be offset by about 1 inch (a few > >> centimeters) when the mode is (re)set during boot. I previously posted > >> both photographs and video of the problem in another "PROBLEM" thread. > > > > [snip] > > > >> I'll look at the patch. Either the EDID is *not* consistent (in which > >> case, why are we not seeing other bugs like this?) or there is something > >> specific to this system or panel used. > > > > Interesting. Or even downright bizarre! Can you disable the caching > > (hopefully the patch is still revertible) and save the EDID > > (/sys/class/drm/card0-LVDS-1/edid) periodically? Might be simplest just to > > dump the EDID every time we probe the LVDS if it has changed. > I have observed major corruption issues for kernel 2.6.37. Sad to hear, but none of what you are describing is related to this bug. This bug has to do specifically with a small patch that added cacheing of EDID panel data under the assumption that it wouldn't change. It only affects your display, not linker, library objects, file systems, or in fact anything other than getting geometry and location on screen right. > Going back to 2.6.36 stable restores things to normality. > I unfortunately do not have time to track down the problem, but I > thought I would mention it as it could be causing your problem. > My problems were: > Corrupting the library cache so that .so files failed to load any more. > Corrupting .o files during compilation so that the linker did not even > recognize them as .o files. > Corrupted data between a DVB card and the recording on the HD. > I am just mentioning it, because the cause might in fact be somewhere else. You might have a bad compiler, be switching distro packages, who knows. Perhaps you can file a detailed bug report explaining your problems on the bugzilla.kernel.org, or followup with more detail (to a new thread). Jon. ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2010-11-11 8:39 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-11-08 10:18 [bisected] offset display bug in i915 Jon Masters 2010-11-08 10:20 ` [Intel-gfx] " Jon Masters 2010-11-08 10:20 ` Jon Masters 2010-11-08 10:27 ` Chris Wilson 2010-11-08 10:54 ` Jon Masters 2010-11-08 11:22 ` [Intel-gfx] " Jon Masters 2010-11-08 11:22 ` Jon Masters 2010-11-08 11:29 ` [Intel-gfx] " Jon Masters 2010-11-08 11:29 ` Jon Masters 2010-11-08 11:36 ` [Intel-gfx] " Jon Masters 2010-11-08 11:36 ` Jon Masters 2010-11-08 12:13 ` [Intel-gfx] " Chris Wilson 2010-11-08 12:13 ` Chris Wilson 2010-11-08 17:58 ` [Intel-gfx] " Jon Masters 2010-11-08 17:58 ` Jon Masters 2010-11-08 23:08 ` [Intel-gfx] " Jon Masters 2010-11-08 23:08 ` Jon Masters 2010-11-08 23:23 ` [OT] avoid preformatting in Evolution (was: [bisected] offset display bug in i915) Paul Menzel 2010-11-08 23:24 ` [PATCH] drm/i915: Fix LVDS fixed-mode regression from 219adae1 Chris Wilson 2010-11-09 0:16 ` Jon Masters 2010-11-11 8:39 ` Jon Masters 2010-11-08 11:33 ` [bisected] offset display bug in i915 James Courtier-Dutton 2010-11-08 11:38 ` Jon Masters 2010-11-08 11:38 ` Jon Masters 2010-11-08 11:26 ` James Courtier-Dutton 2010-11-08 11:34 ` Jon Masters 2010-11-08 11:34 ` Jon Masters
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.