|
Description
peter
2012-02-08 13:13:26 UTC
Created attachment 56767 [details]
dmesg output under Linux 3.2
Created attachment 56768 [details]
Xorg.0.log under Linux v3.1
Created attachment 56769 [details]
dmesg output under Linux 3.1
Sounds like one of the dp bugs we've already fixed in -fixes. Please try the drm-intel-fixes branch from https://git.kernel.org/?p=linux/kernel/git/keithp/linux.git;a=summary I compiled and tested the drm-intel-fixes branch, and it is still faulty, i.e. the display turns off with “no signal” at the maximum resolution. # git describe v3.2-rc2-11398-ge57b688 # uname -a Linux alcyone 3.3.0-rc1+ #1 SMP Wed Feb 8 22:19:11 UTC 2012 x86_64 GNU/Linux As I mentioned above, I had tested the DisplayPort fixes of https://lkml.org/lkml/2012/1/25/204 before, and neither of the patches fixed the regression introduced in commit cd9dde4. Created attachment 56777 [details]
dmesg output under Linux v3.2-rc2-11398-ge57b688
Created attachment 56778 [details]
Xorg.0.log under Linux v3.2-rc2-11398-ge57b688
Created attachment 56779 [details]
xrandr --verbose under Linux v3.2-rc2-11398-ge57b688
Can you please try to disable dp audio when switching to the higher resolution, i.e. xrandr --output DP1 --mode 1920x1080 --set audio off ... or similar. Adding “--set audio off” to xrandr does not help, the display turns off. Do you have an idea why “count” and “clock” differ in [drm:intel_dp_mode_fixup]? # Linux v3.1 [ 34.066974] [drm:intel_dp_mode_fixup], Display port link bw 06 lane count 4 clock 162000 # Linux v3.2 [ 36.514078] [drm:intel_dp_mode_fixup], Display port link bw 0a lane count 2 clock 270000 # Linux v3.2-rc2-11398-ge57b688 (drm-intel-fixes) [ 34.344424] [drm:intel_dp_mode_fixup], Display port link bw 0a lane count 2 clock 270000 For bug CCs not following the intel-gfx mailing list: http://lists.freedesktop.org/archives/intel-gfx/2012-February/015135.html Hi, Is there anything I can do in terms of debugging and testing to help resolve this bug? Debian, for example, has recently updated the kernel of its testing suite to Linux 3.2. Users affected by this bug will likely feel increasingly uncomfortable having to downgrade to an unmaintained Linux 3.1 kernel with potentially unfixed security vulnerabilities. I have tried to revert commit cd9dde4 on the basis of Linux 3.2, but since drm/i915 has undergone quite a few changes since then, this results in conflicts. Which commits would one have to revert in order to cleanly work around the regression introduced by commit cd9dde4? Thanks for any pointers, Peter Yeah looks like we're still getting the link bandwidth calculations wrong, probably by using the wrong value somewhere. I hack to workaround the issue might be to just hard code bpp = 24 in all the calls to intel_dp_link_required(). If that works then it's definitely our problem... Created attachment 59684 [details] [review] recompute 6bpc dithering in mode_fixup Please test this patch and attach full dmesg (with drm.debug=0xe added to your kernel cmdline) to the bug. If your issue is indeed due to 6bpc dithering gone wrong, this might fix it. Should be fixed now (at least it works on my T420 now). Probably due to: commit c4867936474183332db4c19791a65fdad6474fd5 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Apr 10 10:42:36 2012 +0200 drm/i915: properly compute dp dithering for user-created modes which went to stable, so should be in the latest 3.3.x and 3.4.x kernels. I tested Linux commit v3.4-rc3, which contains commit c486793. The issue is *not* resolved in Linux v3.4-rc3. Please, take a look at my initial report again. The bisect shows that this issue first occurs with commit cd9dde4 (October 2011). Whatever needs to be fixed to resolve this problem, the answer is in commit cd9dde4. Thanks, Peter Please boot with drm.debug=0xe added to the kernel cmdline and attach the complete dmesg to this bug report (on 3.4-rc3). Created attachment 60332 [details]
dmesg output with Linux 3.4-rc3
I booted with drm.debug=0xe added to the kernel cmdline (on 3.4-rc3).
The procedure was as follows:
* Reboot from Linux 3.1.8 with DP working at native resolution (1920x1080).
* Boot Linux 3.4-rc3.
* When the i915 is loaded upon boot, the console switches the DP to native resolution, the display works.
* When the X server is loaded, the DP display comes up in 1024x768.
* Switch DP to native resolution using
xrandr --output DP1 --auto
As expected, the display still works, *since we have not power-cycled yet*.
* Unplug power cord of display, and replug.
* The display shows the builtin “power-on without signal” screen ("BenQ", "Energy-saving ..."), and than turns off.
* Switch to 1024x768 using
xrandr --output DP1 --mode 1024x768
* The display turns on in 1024x768 resolution.
* Switch to native resolution using
xrandr --output DP1 --auto
* The display turns off.
The import bit is the power cycling. When rebooting from a working kernel (3.1) to a broken kernel (3.2, 3.3, 3.4-rc), the DP will continue working in native resolution, until the display is power cycled, and after that fail to turn on in native resolution.
Created attachment 60333 [details]
dmesg output with Linux 3.4-rc3 (of a single boot)
I booted with drm.debug=0xe added to the kernel cmdline (on 3.4-rc3).
The procedure was as follows:
* Reboot from Linux 3.1.8 with DP working at native resolution (1920x1080).
* Boot Linux 3.4-rc3.
* When the i915 is loaded upon boot, the console switches the DP to native
resolution, the display works.
* When the X server is loaded, the DP display comes up in 1024x768.
* Switch DP to native resolution using
xrandr --output DP1 --auto
As expected, the display still works, *since we have not power-cycled yet*.
* Unplug power cord of display, and replug.
* The display shows the builtin “power-on without signal” screen ("BenQ",
"Energy-saving ..."), and than turns off.
* Switch to 1024x768 using
xrandr --output DP1 --mode 1024x768
* The display turns on in 1024x768 resolution.
* Switch to native resolution using
xrandr --output DP1 --auto
* The display turns off.
The import bit is the power cycling. When rebooting from a working kernel (3.1) to a broken kernel (3.2, 3.3, 3.4-rc), the DP will continue working in native resolution, until the display is power cycled, and after that fail to turn on in native resolution.
I see different behavior (I'm using drm-intel-next-queued). On boot I get a cloned 1152x864 mode in X. xrandr --output DP1 --auto switches the DP into 1920x1200 when I unplug the power from the DP monitor, X goes to 1600x900 on the local flat panel. when I plug the DP monitor back in, it comes up in its native mode. So I wonder if something is funky with the desktop or X configuration on your system, rather than the kernel... My Xorg configuration is the usual, i.e. there exists no /etc/X11/xorg.conf.
In terms of Xorg configuration, I have these files in /etc/X11/xorg.conf.d/:
# /etc/X11/xorg.conf.d/keyboard.conf
Section "InputClass"
Identifier "Ergonomic Keyboard 4000"
MatchProduct "Ergonomic Keyboard 4000"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
Option "XkbVariant" "basic"
Option "XkbOptions" "compose:menu,caps:super"
EndSection
# Section "InputClass"
Identifier "Trackpoint"
MatchProduct "TrackPoint"
# Enable vertical scrolling
Option "EmulateWheel" "1"
Option "EmulateWheelButton" "2"
Option "EmulateWheelTimeout" "200"
# Enable horizontal scrolling
Option "XAxisMapping" "6 7"
Option "YAxisMapping" "4 5"
EndSection
Could you elaborate on the math “fixed” in commit c486793. What formulas is this commit based on? Could you please explain the details for someone very familiar with math, but not familar with X modes and/or DisplayPort?
Thanks,
Peter
This is on an update-to-date Debian wheezy (amd64) system. We need to calculate the bandwidth that will be used by a given mode configuration so we can configure the DP link for the right clock rate and number of lanes. The fix in commit cd9dde44f47501394b9f0715b6a36a92aa74c0d0 was only a partial one; we were getting the wrong bits per pixel value there until very recently (even now we need to make estimates since we don't have enough information at the time we get called at some points). What's odd is that in your config, you can get the display to come up in its native mode, which means the calculation is working ok in at least some cases. Can you check what pixel_clock and bpp values you get in the successful and failing cases? I wonder if we're failing to propagate data in some cases, or just getting the wrong data altogether... Created attachment 60372 [details] [review] print computed bpp, too Thanks a lot for the detailed description, it's excellent. Unfortunately we miss a little bit of debug info, can you please retry with the attached patch applied? Also, please indicate in your test log the relevant timestamps in dmesg, sometimes it's a bit ambigious to match up what you've done with what's going on in dmesg. Created attachment 60401 [details] [review] print computed bpp, too 3 Even more debug output. Created attachment 60407 [details]
dmesg output with Linux 3.4-rc3 with [PATCH] drm/i915: print computed bpp in dp link configuration
I tested 3.4-rc3 with the patch applied. This time I waited more than a few seconds between each manual action, and dumped dmesg before and after an action, in order to identify them in the kernel log. I hope it helps with the debugging.
Created attachment 60447 [details] [review] force the old dp link configuration Quick patch to force the olde (3.1 kernel) dp link configuration to figure out where the problem. Please test whether this works around the problem. Created attachment 60450 [details]
Linux 3.4-rc3 override intel_dp->link_bw = 0x06, intel_dp->lane_count = 4
Please see the kernel log of 3.4-rc3 with intel_dp->link_bw = 0x06, intel_dp->lane_count = 4.
The manual override works, the display turns on (in native resolution) after power cycle :-).
Another thing to try (attaching dmesg unnecessary) is to disable audio on the dp link with xrandr --output DP1 --auto --set audio off Please refer to https://bugs.freedesktop.org/show_bug.cgi?id=45801#c10 Adding “--set audio off” to xrandr does not help, the display turns off. Is there a way to fix the formula so it computes the correct link_bw and lane_count? Hmm, a 10/8 factor for link required would neatly explain the failure. So are we still failing to account for the 10-bit symbol size... The last review suggested that the link clock already included that factor.
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9919fc0..b3200ea 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -210,7 +210,7 @@ intel_dp_link_clock(uint8_t link_bw)
static int
intel_dp_link_required(int pixel_clock, int bpp)
{
- return (pixel_clock * bpp + 9) / 10;
+ return (pixel_clock * bpp + 9) / 8 * 10 / 10;
}
* kicks himself. You identified the very commit I suspected from the stat. Created attachment 61563 [details] [review] printk if sink request a dp link test Can you please quickly test this debug patch (on a broken kernel) please and check whether anything ends up in dmesg? Created attachment 61576 [details] Linux 3.4-rc3 with printk() in intel_dp_handle_test_request_dmesg Please see the dmesg output, tested with Linux 3.4-rc3 patched to printk() in the function intel_dp_handle_test_request_dmesg. # git log -1 commit e816b57a337ea3b755de72bec38c10c864f23015 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Sun Apr 15 18:28:29 2012 -0700 Linux 3.4-rc3 # git diff diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 4b63791..847b464 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1973,6 +1973,8 @@ intel_dp_handle_test_request(struct intel_dp *intel_dp) { /* NAK by default */ intel_dp_aux_native_write_1(intel_dp, DP_TEST_RESPONSE, DP_TEST_ACK); + + printk("dp link test request received\n"); } /* The output does not contain "dp link test request received", in other words intel_dp_handle_test_request_dmesg is not invoked. For my own notes, to speed up the next test round: git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git git checkout v3.4-rc3 cp ...debian.../config-3.2.0-2-amd64 .config make oldconfig nice make deb-pkg -j 4 INSTALL_MOD_STRIP=1 More notes when testing a (faulty) kernel...
Reboot from Linux 3.1.8 with DP working at native resolution (1920x1080).
Boot Linux <version>.
When the i915 is loaded upon boot, the console switches the DP to native resolution, the display works.
When the X server is loaded, the DP display comes up in 1024x768.
Switch DP to native resolution using
xrandr --output DP1 --auto
As expected, the display still works, since we have not power-cycled yet.
Unplug power cord of display,
and replug.
The display shows the builtin “power-on without signal” screen ("BenQ",
"Energy-saving ..."), and than turns off.
Switch to 1024x768 using
xrandr --output DP1 --mode 1024x768
The display turns on in 1024x768 resolution.
Switch to native resolution using
xrandr --output DP1 --auto
The display turns off.
bugzilla-daemon@freedesktop.org wrote: > For my own notes, to speed up the next test round: Some quick unsolicited tips: ;-) > git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git No need to clone each time --- "git reset --hard" in an existing clone will clear away any changes. > git checkout v3.4-rc3 > cp ...debian.../config-3.2.0-2-amd64 .config > make oldconfig > nice make deb-pkg -j 4 INSTALL_MOD_STRIP=1 "make localmodconfig" can make for faster builds. (It disables modules that are not currently loaded, which presumably are for hardware you don't have or don't use.) "scripts/config --disable DEBUG_INFO" can be used to make the build take less disk space. Hi Jonathan, (In reply to comment #37) > > git checkout v3.4-rc3 > > cp ...debian.../config-3.2.0-2-amd64 .config > > make oldconfig > > nice make deb-pkg -j 4 INSTALL_MOD_STRIP=1 > > "make localmodconfig" can make for faster builds. (It disables > modules that are not currently loaded, which presumably are for > hardware you don't have or don't use.) "scripts/config --disable > DEBUG_INFO" can be used to make the build take less disk space. Thanks, your hints are much appreciated for the next testing ;-). Peter Can you please give us specific details about your monitors make&model and serial number? Sorry for the delay. This is the information from Xorg.0.log for DP1:
[ 51.192] (II) intel(0): EDID for output DP1
[ 51.192] (II) intel(0): Manufacturer: BNQ Model: 8002 Serial#: 21573
[ 51.192] (II) intel(0): Year: 2010 Week: 42
[ 51.192] (II) intel(0): EDID Version: 1.4
[ 51.192] (II) intel(0): Digital Display Input
[ 51.192] (II) intel(0): 8 bits per channel
[ 51.192] (II) intel(0): Digital interface is DisplayPort
[ 51.192] (II) intel(0): Max Image Size [cm]: horiz.: 53 vert.: 30
[ 51.192] (II) intel(0): Gamma: 2.20
[ 51.192] (II) intel(0): DPMS capabilities: Off
[ 51.192] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 YCrCb 4:2:2
[ 51.192] (II) intel(0): Default color space is primary color space
[ 51.192] (II) intel(0): First detailed timing is preferred mode
[ 51.192] (II) intel(0): Preferred mode is native pixel format and refresh rate
[ 51.192] (II) intel(0): redX: 0.643 redY: 0.339 greenX: 0.329 greenY: 0.624
[ 51.192] (II) intel(0): blueX: 0.155 blueY: 0.048 whiteX: 0.313 whiteY: 0.329
[ 51.192] (II) intel(0): Supported established timings:
[ 51.192] (II) intel(0): 640x480@60Hz
[ 51.192] (II) intel(0): 800x600@60Hz
[ 51.192] (II) intel(0): 1024x768@60Hz
[ 51.192] (II) intel(0): Manufacturer's mask: 0
[ 51.192] (II) intel(0): Supported standard timings:
[ 51.192] (II) intel(0): #0: hsize: 1280 vsize 800 refresh: 60 vid: 129
[ 51.192] (II) intel(0): #1: hsize: 1280 vsize 720 refresh: 60 vid: 49281
[ 51.192] (II) intel(0): #2: hsize: 1280 vsize 1024 refresh: 60 vid: 32897
[ 51.193] (II) intel(0): #3: hsize: 1600 vsize 900 refresh: 60 vid: 49321
[ 51.193] (II) intel(0): #4: hsize: 1680 vsize 1050 refresh: 60 vid: 179
[ 51.193] (II) intel(0): #5: hsize: 1920 vsize 1080 refresh: 60 vid: 49361
[ 51.193] (II) intel(0): Supported detailed timing:
[ 51.193] (II) intel(0): clock: 148.5 MHz Image Size: 477 x 268 mm
[ 51.193] (II) intel(0): h_active: 1920 h_sync: 2008 h_sync_end 2052 h_blank_end 2200 h_border: 0
[ 51.193] (II) intel(0): v_active: 1080 v_sync: 1084 v_sync_end 1089 v_blanking: 1125 v_border: 0
[ 51.193] (II) intel(0): Serial No: SAA04093SL0
[ 51.193] (II) intel(0): Ranges: V min: 50 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 175 MHz
[ 51.193] (II) intel(0): Monitor name: BenQ BL2400
[ 51.193] (II) intel(0): EDID (in hex):
[ 51.193] (II) intel(0): 00ffffffffffff0009d1028045540000
[ 51.193] (II) intel(0): 2a140104a5351e783eb7d5a456549f27
[ 51.193] (II) intel(0): 0c5054210800810081c08180a9c0b300
[ 51.193] (II) intel(0): d1c001010101023a801871382d40582c
[ 51.193] (II) intel(0): 4500dd0c1100001e000000ff00534141
[ 51.193] (II) intel(0): 3034303933534c300a20000000fd0032
[ 51.193] (II) intel(0): 4c1e5311000a202020202020000000fc
[ 51.193] (II) intel(0): 0042656e5120424c323430300a2000d4
[ 51.193] (II) intel(0): Printing probed modes for output DP1
[ 51.193] (II) intel(0): Modeline "1920x1080"x60.0 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP)
[ 51.193] (II) intel(0): Modeline "1680x1050"x60.0 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.3 kHz e)
[ 51.193] (II) intel(0): Modeline "1600x900"x60.0 118.96 1600 1696 1864 2128 900 901 904 932 -hsync +vsync (55.9 kHz)
[ 51.193] (II) intel(0): Modeline "1280x1024"x60.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[ 51.193] (II) intel(0): Modeline "1280x800"x59.8 83.50 1280 1352 1480 1680 800 803 809 831 +hsync -vsync (49.7 kHz e)
[ 51.193] (II) intel(0): Modeline "1280x720"x60.0 74.44 1280 1336 1472 1664 720 721 724 746 -hsync +vsync (44.7 kHz)
[ 51.193] (II) intel(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e)
[ 51.193] (II) intel(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e)
[ 51.193] (II) intel(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e)
This is the output from xrandr --verbose for DP1:
DP1 connected 1920x1080+0+0 (0x50) normal (normal left inverted right x axis y axis) 477mm x 268mm
Identifier: 0x44
Timestamp: 95529
Subpixel: unknown
Gamma: 1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC: 1
CRTCs: 0 1
Transform: 1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000
filter:
EDID:
00ffffffffffff0009d1028045540000
2a140104a5351e783eb7d5a456549f27
0c5054210800810081c08180a9c0b300
d1c001010101023a801871382d40582c
4500dd0c1100001e000000ff00534141
3034303933534c300a20000000fd0032
4c1e5311000a202020202020000000fc
0042656e5120424c323430300a2000d4
Broadcast RGB: Full
supported: Full Limited 16:2
audio: auto
supported: off auto on
1920x1080 (0x50) 148.5MHz +HSync +VSync *current +preferred
h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.5KHz
v: height 1080 start 1084 end 1089 total 1125 clock 60.0Hz
1680x1050 (0x51) 146.2MHz -HSync +VSync
h: width 1680 start 1784 end 1960 total 2240 skew 0 clock 65.3KHz
v: height 1050 start 1053 end 1059 total 1089 clock 60.0Hz
1600x900 (0x52) 119.0MHz -HSync +VSync
h: width 1600 start 1696 end 1864 total 2128 skew 0 clock 55.9KHz
v: height 900 start 901 end 904 total 932 clock 60.0Hz
1280x1024 (0x53) 108.0MHz +HSync +VSync
h: width 1280 start 1328 end 1440 total 1688 skew 0 clock 64.0KHz
v: height 1024 start 1025 end 1028 total 1066 clock 60.0Hz
1280x800 (0x54) 83.5MHz +HSync -VSync
h: width 1280 start 1352 end 1480 total 1680 skew 0 clock 49.7KHz
v: height 800 start 803 end 809 total 831 clock 59.8Hz
1280x720 (0x55) 74.4MHz -HSync +VSync
h: width 1280 start 1336 end 1472 total 1664 skew 0 clock 44.7KHz
v: height 720 start 721 end 724 total 746 clock 60.0Hz
1024x768 (0x4c) 65.0MHz -HSync -VSync
h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz
v: height 768 start 771 end 777 total 806 clock 60.0Hz
800x600 (0x4d) 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
640x480 (0x56) 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 60.0Hz
Peter
On Mon, May 21, 2012 at 04:19:18PM +0000, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=45801 > > --- Comment #39 from Daniel Vetter <daniel@ffwll.ch> 2012-05-21 09:19:18 PDT --- > Can you please give us specific details about your monitors make&model and > serial number? Sorry for the delay. This is the information from Xorg.0.log for DP1: [ 51.192] (II) intel(0): EDID for output DP1 [ 51.192] (II) intel(0): Manufacturer: BNQ Model: 8002 Serial#: 21573 [ 51.192] (II) intel(0): Year: 2010 Week: 42 [ 51.192] (II) intel(0): EDID Version: 1.4 [ 51.192] (II) intel(0): Digital Display Input [ 51.192] (II) intel(0): 8 bits per channel [ 51.192] (II) intel(0): Digital interface is DisplayPort [ 51.192] (II) intel(0): Max Image Size [cm]: horiz.: 53 vert.: 30 [ 51.192] (II) intel(0): Gamma: 2.20 [ 51.192] (II) intel(0): DPMS capabilities: Off [ 51.192] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 YCrCb 4:2:2 [ 51.192] (II) intel(0): Default color space is primary color space [ 51.192] (II) intel(0): First detailed timing is preferred mode [ 51.192] (II) intel(0): Preferred mode is native pixel format and refresh rate [ 51.192] (II) intel(0): redX: 0.643 redY: 0.339 greenX: 0.329 greenY: 0.624 [ 51.192] (II) intel(0): blueX: 0.155 blueY: 0.048 whiteX: 0.313 whiteY: 0.329 [ 51.192] (II) intel(0): Supported established timings: [ 51.192] (II) intel(0): 640x480@60Hz [ 51.192] (II) intel(0): 800x600@60Hz [ 51.192] (II) intel(0): 1024x768@60Hz [ 51.192] (II) intel(0): Manufacturer's mask: 0 [ 51.192] (II) intel(0): Supported standard timings: [ 51.192] (II) intel(0): #0: hsize: 1280 vsize 800 refresh: 60 vid: 129 [ 51.192] (II) intel(0): #1: hsize: 1280 vsize 720 refresh: 60 vid: 49281 [ 51.192] (II) intel(0): #2: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 [ 51.193] (II) intel(0): #3: hsize: 1600 vsize 900 refresh: 60 vid: 49321 [ 51.193] (II) intel(0): #4: hsize: 1680 vsize 1050 refresh: 60 vid: 179 [ 51.193] (II) intel(0): #5: hsize: 1920 vsize 1080 refresh: 60 vid: 49361 [ 51.193] (II) intel(0): Supported detailed timing: [ 51.193] (II) intel(0): clock: 148.5 MHz Image Size: 477 x 268 mm [ 51.193] (II) intel(0): h_active: 1920 h_sync: 2008 h_sync_end 2052 h_blank_end 2200 h_border: 0 [ 51.193] (II) intel(0): v_active: 1080 v_sync: 1084 v_sync_end 1089 v_blanking: 1125 v_border: 0 [ 51.193] (II) intel(0): Serial No: SAA04093SL0 [ 51.193] (II) intel(0): Ranges: V min: 50 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 175 MHz [ 51.193] (II) intel(0): Monitor name: BenQ BL2400 [ 51.193] (II) intel(0): EDID (in hex): [ 51.193] (II) intel(0): 00ffffffffffff0009d1028045540000 [ 51.193] (II) intel(0): 2a140104a5351e783eb7d5a456549f27 [ 51.193] (II) intel(0): 0c5054210800810081c08180a9c0b300 [ 51.193] (II) intel(0): d1c001010101023a801871382d40582c [ 51.193] (II) intel(0): 4500dd0c1100001e000000ff00534141 [ 51.193] (II) intel(0): 3034303933534c300a20000000fd0032 [ 51.193] (II) intel(0): 4c1e5311000a202020202020000000fc [ 51.193] (II) intel(0): 0042656e5120424c323430300a2000d4 [ 51.193] (II) intel(0): Printing probed modes for output DP1 [ 51.193] (II) intel(0): Modeline "1920x1080"x60.0 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP) [ 51.193] (II) intel(0): Modeline "1680x1050"x60.0 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.3 kHz e) [ 51.193] (II) intel(0): Modeline "1600x900"x60.0 118.96 1600 1696 1864 2128 900 901 904 932 -hsync +vsync (55.9 kHz) [ 51.193] (II) intel(0): Modeline "1280x1024"x60.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e) [ 51.193] (II) intel(0): Modeline "1280x800"x59.8 83.50 1280 1352 1480 1680 800 803 809 831 +hsync -vsync (49.7 kHz e) [ 51.193] (II) intel(0): Modeline "1280x720"x60.0 74.44 1280 1336 1472 1664 720 721 724 746 -hsync +vsync (44.7 kHz) [ 51.193] (II) intel(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 51.193] (II) intel(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 51.193] (II) intel(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) This is the output from xrandr --verbose for DP1: DP1 connected 1920x1080+0+0 (0x50) normal (normal left inverted right x axis y axis) 477mm x 268mm Identifier: 0x44 Timestamp: 95529 Subpixel: unknown Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 1 CRTCs: 0 1 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: EDID: 00ffffffffffff0009d1028045540000 2a140104a5351e783eb7d5a456549f27 0c5054210800810081c08180a9c0b300 d1c001010101023a801871382d40582c 4500dd0c1100001e000000ff00534141 3034303933534c300a20000000fd0032 4c1e5311000a202020202020000000fc 0042656e5120424c323430300a2000d4 Broadcast RGB: Full supported: Full Limited 16:2 audio: auto supported: off auto on 1920x1080 (0x50) 148.5MHz +HSync +VSync *current +preferred h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.5KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.0Hz 1680x1050 (0x51) 146.2MHz -HSync +VSync h: width 1680 start 1784 end 1960 total 2240 skew 0 clock 65.3KHz v: height 1050 start 1053 end 1059 total 1089 clock 60.0Hz 1600x900 (0x52) 119.0MHz -HSync +VSync h: width 1600 start 1696 end 1864 total 2128 skew 0 clock 55.9KHz v: height 900 start 901 end 904 total 932 clock 60.0Hz 1280x1024 (0x53) 108.0MHz +HSync +VSync h: width 1280 start 1328 end 1440 total 1688 skew 0 clock 64.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 60.0Hz 1280x800 (0x54) 83.5MHz +HSync -VSync h: width 1280 start 1352 end 1480 total 1680 skew 0 clock 49.7KHz v: height 800 start 803 end 809 total 831 clock 59.8Hz 1280x720 (0x55) 74.4MHz -HSync +VSync h: width 1280 start 1336 end 1472 total 1664 skew 0 clock 44.7KHz v: height 720 start 721 end 724 total 746 clock 60.0Hz 1024x768 (0x4c) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 800x600 (0x4d) 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 640x480 (0x56) 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 60.0Hz Peter Hi,
I have same problem as described in this bug. I have laptop (HP ProBook 6360b) with DisplayPort video output (only external video output). Until Kernel 3.1, everything was working, but with Kernel 3.2 (and later), I can't use native resolution on my Fujitsu P23T-6 IPS monitor, which is 1920x1080. Interesting thing is, that I can use any other resolution on this monitor without problem (on Kernel 3.2 and later), just not the native one. I also have HP monitor at home, which have native resolution 1920x1200 and this monitor has no problem with latest kernels.
If I can provide some useful information, please tell me, which commands output you need.
Here I'm sending part of "xrandr --current --verbose" command. This is from Kernel 3.1.10-030110-generic #201201181135 (running on Ubuntu 12.04). Would info from Kernel 3.2 be helpful?
DP3 connected 1920x1080+0+0 (0xd4) normal (normal left inverted right x axis y axis) 509mm x 286mm
Identifier: 0x48
Timestamp: 326240
Subpixel: unknown
Gamma: 1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC: 0
CRTCs: 1 0
Transform: 1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000
filter:
EDID:
00ffffffffffff001ab3e9071c010000
2d140104a5331d783afe25a85337ae24
115054a54b00a940b300950081008180
010101010101023a801871382d40582c
9600fd1e11000018000000fd00314c0f
5211000a202020202020000000fc0050
3233542d36204950530a2020000000ff
00595633513030303238340a20200153
020318744b909f859404130312010211
2309070783010000023a80d072382d40
102c9680fd1d11000018283c80a070b0
234030203600fd1e1100001a011d00bc
52d01e20b8285540fd1e1100001e011d
007251d01e206e285500fd1e1100001e
8c0ad090204031200c405500fd1e1100
0018000000000000000000000000002a
Broadcast RGB: Full
supported: Full Limited 16:2
audio: off
supported: off auto on
1920x1080 (0xd4) 148.5MHz -HSync -VSync *current +preferred
h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.5KHz
v: height 1080 start 1089 end 1095 total 1125 clock 60.0Hz
1920x1200 (0xd5) 154.0MHz +HSync -VSync
h: width 1920 start 1968 end 2000 total 2080 skew 0 clock 74.0KHz
v: height 1200 start 1203 end 1209 total 1235 clock 60.0Hz
1920x1080 (0xd6) 148.5MHz -HSync -VSync
h: width 1920 start 2448 end 2492 total 2640 skew 0 clock 56.2KHz
v: height 1080 start 1089 end 1095 total 1125 clock 50.0Hz
1600x1200 (0xd7) 162.0MHz +HSync +VSync
h: width 1600 start 1664 end 1856 total 2160 skew 0 clock 75.0KHz
v: height 1200 start 1201 end 1204 total 1250 clock 60.0Hz
1680x1050 (0xd8) 146.2MHz -HSync +VSync
h: width 1680 start 1784 end 1960 total 2240 skew 0 clock 65.3KHz
v: height 1050 start 1053 end 1059 total 1089 clock 60.0Hz
1280x1024 (0xd9) 135.0MHz +HSync +VSync
h: width 1280 start 1296 end 1440 total 1688 skew 0 clock 80.0KHz
v: height 1024 start 1025 end 1028 total 1066 clock 75.0Hz
1280x1024 (0xda) 108.0MHz +HSync +VSync
h: width 1280 start 1328 end 1440 total 1688 skew 0 clock 64.0KHz
v: height 1024 start 1025 end 1028 total 1066 clock 60.0Hz
1440x900 (0xdb) 106.5MHz -HSync +VSync
h: width 1440 start 1520 end 1672 total 1904 skew 0 clock 55.9KHz
v: height 900 start 903 end 909 total 934 clock 59.9Hz
1280x800 (0xdc) 83.5MHz +HSync -VSync
h: width 1280 start 1352 end 1480 total 1680 skew 0 clock 49.7KHz
v: height 800 start 803 end 809 total 831 clock 59.8Hz
1280x720 (0xdd) 74.2MHz +HSync +VSync
h: width 1280 start 1390 end 1430 total 1650 skew 0 clock 45.0KHz
v: height 720 start 725 end 730 total 750 clock 60.0Hz
1280x720 (0xde) 74.2MHz +HSync +VSync
h: width 1280 start 1720 end 1760 total 1980 skew 0 clock 37.5KHz
v: height 720 start 725 end 730 total 750 clock 50.0Hz
1024x768 (0xdf) 78.8MHz +HSync +VSync
h: width 1024 start 1040 end 1136 total 1312 skew 0 clock 60.1KHz
v: height 768 start 769 end 772 total 800 clock 75.1Hz
1024x768 (0x4c) 65.0MHz -HSync -VSync
h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz
v: height 768 start 771 end 777 total 806 clock 60.0Hz
800x600 (0xe0) 49.5MHz +HSync +VSync
h: width 800 start 816 end 896 total 1056 skew 0 clock 46.9KHz
v: height 600 start 601 end 604 total 625 clock 75.0Hz
800x600 (0x4d) 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
640x480 (0xe1) 31.5MHz -HSync -VSync
h: width 640 start 656 end 720 total 840 skew 0 clock 37.5KHz
v: height 480 start 481 end 484 total 500 clock 75.0Hz
640x480 (0xe2) 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 60.0Hz
720x400 (0xe3) 28.3MHz -HSync +VSync
h: width 720 start 738 end 846 total 900 skew 0 clock 31.5KHz
v: height 400 start 412 end 414 total 449 clock 70.1Hz
Best regards,
Jan
Jan, can you please open a new report for your issue? I know, duplicate bugs are in most bugzillas frowned upon, but graphics bugs are rather hard to pinpoint, so I prefer to keep bugs separate until we have solid proof that they are duplicates. And similar symptoms are rather far from that. Now to diagnose your issue, can you please try out the latest 3.5-rc kernel, boot with drm.debug=0xe and try out both the broken and the working monitor. Then please attach the full dmesg to your bug report (not this one here, otherwise we'll quickly have a chaos). Created attachment 63320 [details] [review] prefer many lanes and slow clocks to fast clocks with few lanes This bug bugs me. Can you try this crazy patch and see if it helps? It might get you closer to your old config... On Thu, Jun 21, 2012 at 11:59:59AM +0000, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=45801 > > --- Comment #44 from Jesse Barnes <jbarnes@virtuousgeek.org> 2012-06-21 11:59:59 UTC --- > Created attachment 63320 [details] [review] > --> https://bugs.freedesktop.org/attachment.cgi?id=63320 > prefer many lanes and slow clocks to fast clocks with few lanes > > This bug bugs me. Can you try this crazy patch and see if it helps? It might > get you closer to your old config... Please see the attachment, I tested 3.4.0-rc3 with the patch applied, and it works! With the crazy patch I get native resolution, even after power cycling twice. Thanks! Now the only thing missing is a sane commit message? :-) Peter Created attachment 63324 [details]
Linux 3.4.0-rc3 with patch "prefer many lanes and slow clocks to fast clocks with few lanes"
Oh great... my main worry about this patch is that it'll cause regressions with other configs. But the theory is that cheap and/or long DP cables might not be able to transmit at high frequency well enough to sync and train the link. Testing that theory is optional though, I think we can put this patch into -next and get a bunch of people banging on it. On Thu, Jun 21, 2012 at 10:10:57PM +0000, bugzilla-daemon@freedesktop.org wrote: > --- Comment #47 from Jesse Barnes <jbarnes@virtuousgeek.org> 2012-06-21 15:10:57 PDT --- > Oh great... my main worry about this patch is that it'll cause regressions with > other configs. > > But the theory is that cheap and/or long DP cables might not be able to > transmit at high frequency well enough to sync and train the link. Testing > that theory is optional though, I think we can put this patch into -next and > get a bunch of people banging on it. The display is connected with an iCAN Premium DisplayPort 1080p cable, 3 m long. In terms of price, it was certainly not cheap (13% of the price of the display). Must just be the length then. 3m is a pretty long cable. It's possible there's a vswing, preemphasis, and precharge that would make it work at high freq, but the lower frequency is probably better anyway. so, there are two reasons to prefer fewer lanes:
1) Lower power usage. Lighting up two lanes instead of four
should reduce power usage, even running them at a higher data
I've merged Jesse's patch to drm-intel-next-queued as: commit 684aaa646f90f5ee07799d52d0735625756e607b Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Jun 21 15:13:50 2012 -0700 drm/i915: prefer wide & slow to fast & narrow in DP configs A patch referencing this bug report has been merged in Linux v3.6-rc1: commit 2514bc510d0c3aadcc5204056bb440fa36845147 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Jun 21 15:13:50 2012 -0700 drm/i915: prefer wide & slow to fast & narrow in DP configs "A patch referencing this bug report has been merged" -> closed. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.