Created attachment 84775 [details] system boots and sets display modes System Environment: -------------------------- Kernel: (drm-intel-nightly)94814d0f36b38c38700bee6ef64de44a32601cba Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Aug 26 19:51:00 2013 -0300 drm/i915: Always prefer CPU relocations with LLC Bug Details: -------------------------- These two modes can't light up on DP. [2] 1856x1392 60 1856 1952 2176 2528 1392 1393 1396 1439 0x6 0x40 218250 [3] 1792x1344 60 1792 1920 2120 2448 1344 1345 1348 1394 0x6 0x40 204750 This is the first time I use the monitor which has these two modes, we bought this monitor some time ago. I attach the dmesg of system booting and setting this two modes.
Does this only happen on SNB or also on other platforms like IVB/HSW?
(In reply to comment #1) > Does this only happen on SNB or also on other platforms like IVB/HSW? I specifically borrowed machine with DP and found that all platforms including ILK/SNB/IVB/HSW have this issue.
Can you please check with a Windows machine whether it works there with these resolutions? Could be that we need to quirk the monitor ...
(In reply to comment #3) > Can you please check with a Windows machine whether it works there with > these resolutions? Could be that we need to quirk the monitor ... I use a windows 8 machine(Intel Graphics Driver PV9.10) but it doesn't seem to support custom resolution. This custom resolution feature is supported in production versions 14.34 and 15.9 and later versions of the Intel graphics driver. I can't get any of these versions.. So, I can't say if the two modes can work right on Windows machine.
Hi Your dmesg is not full, it doesn't contain the very beginning. Please increase the value of CONFIG_LOG_BUF_SHIFT. Also, can you please send us the output of "xrandr --verbose"? I think the first step is to discover why we're creating these modes: they don't look like standard modes, so maybe we shouldn't add these modes to the list at all. Thanks, Paulo
Created attachment 85163 [details] 1792x1344@60
Created attachment 85164 [details] 1856x1392@60
(In reply to comment #3) > Can you please check with a Windows machine whether it works there with > these resolutions? Could be that we need to quirk the monitor ... I retest it with a Windows 8 professional machine and find mode 1856x1392@60 can display normal, but mode 1792x1344@60 display center. So I think the monitor is ok. I attached two pictures of these two modes.
(In reply to comment #5) > Hi > > Your dmesg is not full, it doesn't contain the very beginning. Please > increase the value of CONFIG_LOG_BUF_SHIFT. > > Also, can you please send us the output of "xrandr --verbose"? > > I think the first step is to discover why we're creating these modes: they > don't look like standard modes, so maybe we shouldn't add these modes to the > list at all. > > Thanks, > Paulo Hi, I added log_buf_len=4M to kernel command and grabbed the dmesg again, and I hope it will be useful. I also attached the "xrandr --verbose", this two modes can display at a windows machine like the two pictures I attached. :)
Created attachment 85165 [details] xrandr --verbose
Created attachment 85166 [details] dmesg with log_buf_len=4M
Timeout. Please re-test with current drm-intel-nightly.
(In reply to comment #12) > Timeout. Please re-test with current drm-intel-nightly. I find that only one monitor supports 1792x1344 and 1856x1392 resolution, which failed to be lighted up by latest -nightly kernel on one HSW machine. I-G-T testdisplay can detect the DP monitor.
Created attachment 105951 [details] new-dmesg-hsw
Woo more link training failures and pipe off wait failures. Something is still wrong with our mode set sequence for DP...
Any update on this with current bits? Maybe some of Jani's AUX fixes might help here, dunno.
The bug still exists on latest drm-intel-testing.
Monitor model No: ViewSonic VS14703. EDID: 00ffffffffffff005a632b8301010101 33160104b53c22783f2595a9544fa126 0a5054bfef80e1c0d100d1c0b300a940 a9c095008180565e00a0a0a029503020 350055502100001a000000ff00544450 3132353130303031390a000000fc0056 503237373020534552494553000000fd 00324b0f5e1b000a20202020202001e8 020320f153900504030207060f0e1f14 13121116151e1d0123097f0783010000 023a801871382d40582c450055502100 001e011d007251d01e206e2855005550 2100001e8c0ad08a20e02d10103e9600 555021000018011d8018711c1620582c 250055502100009e023a80d072382d40 102c458055502100001e000000000077
Notice that DMT v1.0 write: +------------+----------------+----------+--------------+---------------+ | Pixel | Refresh Rate | DMT ID | STD | CVT | | Format | | Codes |2 Byte Codes |3 Byte Codes | +------------+----------------+----------+--------------+---------------+ |1856 x 1392 | 60 Hz | 41h | (C9, 40)h | n/a | +------------+----------------+----------+--------------+---------------+ |1792 x 1344 | 60 Hz | 3Eh | (C1, 40)h | n/a | +------------+----------------+----------+--------------+---------------+ This two modes is n/a in CVT table. Does this have some influence on display? I ever did a test as below steps: 1. cvt 1856 1392 60(I get 8 display timing) 2. replace 1856x1392 display timing in drm display mode table which is defined in drm_edid.c . 3. build kernel 4. 1856x1392 mode can be lighted up with the kernel. 1792x1344 mode is the same.
Timeout, closing. Please reopen if the problem persists with latest kernels.
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.