Bug 106596 - [snb DP-to-DVI dongle] miniDP to external monitor with DVI-D via miniDP to DVI-D adapter and blank screen
Summary: [snb DP-to-DVI dongle] miniDP to external monitor with DVI-D via miniDP to DV...
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Manasi
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-21 19:37 UTC by genpur
Modified: 2019-11-29 17:47 UTC (History)
2 users (show)

See Also:
i915 platform: SNB
i915 features: display/DP

Attachments
logs : dmesg, xrandr, Xorg.0.log (132.62 KB, application/zip)
2018-05-21 19:37 UTC, genpur 		no flags Details
dmesg_case01_adapter_connected_on_the_beginning (121.36 KB, text/plain)
2018-05-23 20:38 UTC, genpur 		no flags Details
dmesg_case01_adapter_disconnected_on_the_beggining (113.72 KB, text/plain)
2018-05-23 20:39 UTC, genpur 		no flags Details
drm_dp_aux0_kernel_4.16.10_adapter_and_monitor_plugged_from_booting (1.00 MB, application/octet-stream)
2018-05-26 17:43 UTC, genpur 		no flags Details
drm_dp_aux0_kernel_4.16.10_plugged_in_adapter_ONLY (1.00 MB, application/octet-stream)
2018-05-26 17:45 UTC, genpur 		no flags Details
drm_dp_aux0_kernel_4.16.10_plugged_in_adapter_and_detected_PanasonicTV (1.00 MB, application/octet-stream)
2018-05-26 17:47 UTC, genpur 		no flags Details
drm_dp_aux0_kernel_4.10.17_adapter_and_detected_monitor_plugged_from_booting_with_param_video_DP-1:D (1.00 MB, text/x-hex)
2018-05-26 17:50 UTC, genpur 		no flags Details
View All

Description genpur 2018-05-21 19:37:03 UTC 
Created attachment 139667 [details]
logs : dmesg, xrandr,  Xorg.0.log

Connection from miniDP port (Intel HD Graphics 3000) to DVI-D input of external monitor (iiyama ProLite E1900S) via miniDP to DVI-D adapter (Startech MDP2DVIS).

Laptop specification:
Dell XPS L502x with Optimus combo

lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GF108M [GeForce GT 525M] (rev ff)

This bug is kind of continuation of https://bugs.freedesktop.org/show_bug.cgi?id=105891
Previous adapter has been tested with your suggestions (different cables and so on). I gave up with previous adapter when I have checked that it doesn't work even with Windows.

Now I have new adapter from Startech. It works with Win10 and Win7sp1. I have installed Win7sp1 on separate disk and external monitor works perfect after installing Intel HD Graphics drivers.
My point is to work with external monitor on Linux without problems. I did many tests and I can separate few cases.


CASE 01) On Linux external monitor is not detected automatically (I have checked many kernels 4.x including the latest 4.16.x)

`xrandr` command returns :
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
LVDS-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 193mm
   1920x1080     60.01*+  59.93  
   1680x1050     59.95    59.88  
   1600x1024     60.17  
   1400x1050     59.98  
   1280x1024     60.02  
   1440x900      59.89  
   1280x960      60.00  
   1360x768      59.80    59.96  
   1152x864      60.00  
   1024x768      60.04    60.00  
   960x720       60.00  
   928x696       60.05  
   896x672       60.01  
   960x600       60.00  
   960x540       59.99  
   800x600       60.00    60.32    56.25  
   840x525       60.01    59.88  
   800x512       60.17  
   700x525       59.98  
   640x512       60.02  
   720x450       59.89  
   640x480       60.00    59.94  
   680x384       59.80    59.96  
   576x432       60.06  
   512x384       60.00  
   400x300       60.32    56.34  
   320x240       60.05  
VGA-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)





CASE 02) On Linux (kernels <= 4.10.x) it's possible to manually activate external monitor (with some limits pointed below) when system is fully started :

Generated entries with cvt :
"640x480_60.00"   23.75  640 664 720 800  480 483 487 500 -hsync +vsync
"640x480_75.00"   30.75  640 664 728 816  480 483 487 504 -hsync +vsync
"800x600_60.00"   38.25  800 832 912 1024  600 603 607 624 -hsync +vsync
"800x600_75.00"   49.00  800 840 920 1040  600 603 607 629 -hsync +vsync
"1024x768_60.00"   63.50  1024 1072 1176 1328  768 771 775 798 -hsync +vsync
"1024x768_75.00"   82.00  1024 1088 1192 1360  768 771 775 805 -hsync +vsync
"1280x1024_60.00"  109.00  1280 1368 1496 1712  1024 1027 1034 1063 -hsync +vsync
"1280x1024_75.00"  138.75  1280 1368 1504 1728  1024 1027 1034 1072 -hsync +vsync

Modes added manually with xrandr :
xrandr --newmode "${entry_xrandr}"
xrandr --addmode "${output}" ${xrandr_mode}
xrandr --output "${output}" --mode ${xrandr_mode}

`xrandr` command returns :
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
(...)
DP-1 disconnected (normal left inverted right x axis y axis)
   640x480_60.00  59.38  
   640x480_75.00  74.77  
   800x600_60.00  59.86  
   800x600_75.00  74.91  
   1024x768_60.00  59.92  
   1024x768_75.00  74.90  
   1280x1024_60.00  59.89  
   1280x1024_75.00  74.90

Mode "1280x1024_75.00" activation :
xrandr --output DP-1 --mode 1280x1024_75.00 --right-of LVDS-1

`xrandr` command returns :
Screen 0: minimum 320 x 200, current 3200 x 1080, maximum 8192 x 8192
(...)
DP-1 disconnected 1280x1024+1920+0 (normal left inverted right x axis y axis) 0mm x 0mm
   640x480_60.00  59.38  
   640x480_75.00  74.77  
   800x600_60.00  59.86  
   800x600_75.00  74.91  
   1024x768_60.00  59.92  
   1024x768_75.00  74.90  
   1280x1024_60.00  59.89  
   1280x1024_75.00  74.90* 

Question : Why does external monitor works now, but status is "disconnected" ??? Additionally any graphical applications like LXRandR does not allow to change mode of DP-1 to any others. DP-1 is simple not available in this case. Is it normal ?





CASE 03) On Linux (kernels <= 4.10.x) it's possible to activate external monitor (without any limits like in case 02) with grub2 parameters on command line :
	drm.debug=0xe video=DP-1:1280x1024@60D

`xrandr` command returns :
Screen 0: minimum 320 x 200, current 3200 x 1080, maximum 8192 x 8192
(...)
DP-1 connected 1280x1024+1920+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024     60.02*+  75.02  
   1280x960      60.00  
   1152x864      75.00  
   1024x768      75.03    70.07    60.00  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   640x480       75.00    72.81    66.67    59.94  
   720x400       70.08 

Now everything works perfect. External screen is activated during system start-up even before login manager is shown. Xrandr shows status "connected", graphical applications like LXRandR allows to change to any of all properly discovered modes. Perfect! No questions.





CASE 04) On Linux (kernels >= 4.11.x) it's NOT POSSIBLE to activate external monitor with grub2 parameters on command line :
	drm.debug=0xe video=DP-1:1280x1024@60D

`xrandr` command returns :
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
(...)
DP-1 connected (normal left inverted right x axis y axis)


I have also tried to manually add modes (like in case 02), but I have got error:
xrandr --output DP-1 --mode 1280x1024_75.00 --right-of LVDS-1
xrandr: Configure crtc 1 failed

`xrandr` command returns :
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
(...)
DP-1 connected (normal left inverted right x axis y axis)
   640x480_60.00  59.38  
   640x480_75.00  74.77  
   800x600_60.00  59.86  
   800x600_75.00  74.91  
   1024x768_60.00  59.92  
   1024x768_75.00  74.90  
   1280x1024_60.00  59.89  
   1280x1024_75.00  74.90  


Question : Why do the latest kernels (I have checked 4.11 up to 4.17-rc5) not have this functionality ? It's not possible to activate external monitor by no means. 

In my opinion normally external monitor should be activated automatically (case 01), but it will be enough if all the kernels >= 4.11.x (case 04) will allow to achieve it, even with extra kernel parameters added to grub2 (like in case 03).
Best regards.
Comment 1 Jani Nikula 2018-05-23 14:51:24 UTC 
(In reply to genpur from comment #0)
> Created attachment 139667 [details]
> logs : dmesg, xrandr,  Xorg.0.log

Please attach each one individually as plain text. Please add drm.debug=14 and capture dmesg from boot to the problem on the latest kernel you can get your hands on, for the case 01 you describe.

Does it make a difference if the system is booted with the cable connected/disconnected? Please try unplug/plug and have that included in the dmesg.
Comment 2 genpur 2018-05-23 20:38:44 UTC 
Created attachment 139721 [details]
dmesg_case01_adapter_connected_on_the_beginning
Comment 3 genpur 2018-05-23 20:39:37 UTC 
Created attachment 139722 [details]
dmesg_case01_adapter_disconnected_on_the_beggining
Comment 4 genpur 2018-05-23 20:54:22 UTC 
I added both dmesg logs - system started with adapter(and DVI cable) connected to external monitor and system started with adapter disconnected. For both cases I have plugged/unplugged adapter few times. It's registered in dmesg.
I don't know is it something strange/important for you, but I saw that connecting and disconnecting only the cable (which connects adapter with monitor) when adapter is connected of course, does nothing even dmesg does not register any action.
Comment 5 Jani Nikula 2018-05-24 07:34:05 UTC 
From logs

[    1.854035] [drm:intel_dp_detect [i915]] [CONNECTOR:63:DP-1]
[    1.854896] [drm:intel_dp_read_dpcd [i915]] DPCD: 11 0a 82 01 01 05 01 81 00 01 04 01 0f 00 00
[    1.855591] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:63:DP-1] status updated from unknown to disconnected
[    1.855595] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:63:DP-1] disconnected

we can read the DPCD but we decide nothing's there after all.

Would be great to be able to get the sink count from the dongle. Do you have CONFIG_DRM_DP_AUX_CHARDEV=y? i.e. do you have /dev/drm_dp_auxN devices, N is 0-based number?

What does this output:

# dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200)) count=1 | od -tx1
Comment 6 Jani Nikula 2018-05-24 07:34:42 UTC 
Cc: Ville
Comment 7 genpur 2018-05-24 11:08:58 UTC 
Kernel (4.16.10) has been built with "CONFIG_DRM_DP_AUX_CHARDEV=y" configuration.
Additionally I have also checked few kernels from 4.4 up to 4.16 and all of them have been built with this configuration.

Device /dev/drm_dp_aux0 exists in my system :
LC_MESSAGES=en_UK.UTF-8 ls -lah /dev/drm_dp_aux*
crw------- 1 root root 243, 0 May 24  2018 /dev/drm_dp_aux0


When adapter is disconnected :
LC_MESSAGES=en_UK.UTF-8 sudo dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200)) count=1 | od -tx1
dd: error reading '/dev/drm_dp_aux0': Connection timed out
0+0 records in
0+0 records out
0 bytes copied, 0.0804776 s, 0.0 kB/s
0000000

When adapter is connected :
LC_MESSAGES=en_UK.UTF-8 sudo dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200)) count=1 | od -tx1
1+0 records in
1+0 records out
1 byte copied, 0.000779381 s, 1.3 kB/s
0000000 00
0000001


Another info for you :
I have discovered that when system is started with kernel <= 4.10 with kernel parameter "video=DP-1:D" then it doesn't matter if adapter was plugged or unplugged while booting. External monitor is activated anytime adapter is plugged to the laptop. All the resolutions/refresh rates are available according to technical specification of the monitor, so EDID seems to be read corectly and seems to be not corrupted.
In this case the command "dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200)) count=1 | od -tx1" also returns "00".
Comment 8 Jani Nikula 2018-05-25 17:01:54 UTC 
Not exactly dupe, but possibly the same fix would cover this bug and bug 106291.
Comment 9 Jani Nikula 2018-05-25 17:12:21 UTC 
(In reply to genpur from comment #7)
> When adapter is disconnected :
> LC_MESSAGES=en_UK.UTF-8 sudo dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200))
> count=1 | od -tx1
> dd: error reading '/dev/drm_dp_aux0': Connection timed out

As expected.

> When adapter is connected :
> LC_MESSAGES=en_UK.UTF-8 sudo dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200))
> count=1 | od -tx1
> 1+0 records in
> 1+0 records out
> 1 byte copied, 0.000779381 s, 1.3 kB/s
> 0000000 00

That 00 tells us the adapter thinks there are no displays connected to it. That should dynamically change depending on the display being plugged/unplugged into the other end of the cable, and generate a hotplug event. Please double check with a display, and ensure it's on.

How about

dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x80)) count=16 | od -tx1

Ville, perhaps we should only trust sink count if downstream port is hotplug capable, and assume 1 otherwise? Regardless of what the spec says. See the sink count handling in intel_dp_detect_dpcd() - we never reach that if sink count is 0 in intel_dp_get_dpcd(). Not very consistent.
Comment 10 Jani Nikula 2018-05-25 17:20:00 UTC 
(In reply to Jani Nikula from comment #8)
> Not exactly dupe, but possibly the same fix would cover this bug and bug
> 106291.

Err, not really. But it's related. Maybe. :)
Comment 11 Ville Syrjala 2018-05-25 18:06:38 UTC 
(In reply to Jani Nikula from comment #9)
> (In reply to genpur from comment #7)
> > When adapter is disconnected :
> > LC_MESSAGES=en_UK.UTF-8 sudo dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200))
> > count=1 | od -tx1
> > dd: error reading '/dev/drm_dp_aux0': Connection timed out
> 
> As expected.
> 
> > When adapter is connected :
> > LC_MESSAGES=en_UK.UTF-8 sudo dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200))
> > count=1 | od -tx1
> > 1+0 records in
> > 1+0 records out
> > 1 byte copied, 0.000779381 s, 1.3 kB/s
> > 0000000 00
> 
> That 00 tells us the adapter thinks there are no displays connected to it.
> That should dynamically change depending on the display being
> plugged/unplugged into the other end of the cable, and generate a hotplug
> event. Please double check with a display, and ensure it's on.
> 
> How about
> 
> dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x80)) count=16 | od -tx1
> 
> Ville, perhaps we should only trust sink count if downstream port is hotplug
> capable, and assume 1 otherwise? Regardless of what the spec says. See the
> sink count handling in intel_dp_detect_dpcd() - we never reach that if sink
> count is 0 in intel_dp_get_dpcd(). Not very consistent.

IIRC I was arguing about SINK_COUNT vs. hpd capable years ago with someone. Can't really remember what the issue was though.

Reporter, please attach the full dpcd dump from 'dd if=/dev/drm_dp_aux0' to the bug (should be 1MiB in size, if it comes out short use ddrescue instead). Do make sure the display is powered on and connected to the dongle when you do this.
Comment 12 genpur 2018-05-26 17:36:49 UTC 
(In reply to Jani Nikula from comment #9)
> (In reply to genpur from comment #7)
> > When adapter is disconnected :
> > LC_MESSAGES=en_UK.UTF-8 sudo dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200))
> > count=1 | od -tx1
> > dd: error reading '/dev/drm_dp_aux0': Connection timed out
> 
> As expected.
> 
> > When adapter is connected :
> > LC_MESSAGES=en_UK.UTF-8 sudo dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200))
> > count=1 | od -tx1
> > 1+0 records in
> > 1+0 records out
> > 1 byte copied, 0.000779381 s, 1.3 kB/s
> > 0000000 00
> 
> That 00 tells us the adapter thinks there are no displays connected to it.
> That should dynamically change depending on the display being
> plugged/unplugged into the other end of the cable, and generate a hotplug
> event. Please double check with a display, and ensure it's on.
> 
> How about
> 
> dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x80)) count=16 | od -tx1
> 
> Ville, perhaps we should only trust sink count if downstream port is hotplug
> capable, and assume 1 otherwise? Regardless of what the spec says. See the
> sink count handling in intel_dp_detect_dpcd() - we never reach that if sink
> count is 0 in intel_dp_get_dpcd(). Not very consistent.

dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x80)) count=16 | od -tx1 returns always(*):
0000000 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

(*)always - means for all the cases I have checked when adapter was plugged in to PC and : kernels 4.16, 4.10, monitor undetected or other TV display detected.
Comment 13 genpur 2018-05-26 17:43:14 UTC 
Created attachment 139792 [details]
drm_dp_aux0_kernel_4.16.10_adapter_and_monitor_plugged_from_booting
Comment 14 genpur 2018-05-26 17:45:50 UTC 
Created attachment 139793 [details]
drm_dp_aux0_kernel_4.16.10_plugged_in_adapter_ONLY
Comment 15 genpur 2018-05-26 17:47:52 UTC 
Created attachment 139794 [details]
drm_dp_aux0_kernel_4.16.10_plugged_in_adapter_and_detected_PanasonicTV
Comment 16 genpur 2018-05-26 17:50:01 UTC 
Created attachment 139795 [details]
drm_dp_aux0_kernel_4.10.17_adapter_and_detected_monitor_plugged_from_booting_with_param_video_DP-1:D
Comment 17 genpur 2018-05-26 17:58:19 UTC 
(In reply to Ville Syrjala from comment #11)
> 
> Reporter, please attach the full dpcd dump from 'dd if=/dev/drm_dp_aux0' to
> the bug (should be 1MiB in size, if it comes out short use ddrescue
> instead). Do make sure the display is powered on and connected to the dongle
> when you do this.

To avoid missunderstanding I want to point attachment under Comment 13 is answer for your request :
https://bugs.freedesktop.org/show_bug.cgi?id=106596#c13

The rest of attachents are extra tests which might be helpful, maybe...
Panasonic TV used here is other display I have checked. TV is detected corectly.
Comment 18 Lakshmi 2018-09-10 15:58:03 UTC 
Reporter, do you still have the issue?
Please try to reproduce the issue using drm-tip (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot.
Comment 19 genpur 2018-09-14 13:58:53 UTC 
Do I have to clone any branch of "drm-tip" via "git clone ..." ? Or maybe download the kernel source, copy some files from cgit.freedesktop.org/drm/drm-tip/ , patch the source files  and proceed full kernel compilation ...? Could you give me some tips how should I use "drm-tip", please? Thank you in advance for help.
Comment 20 Ville Syrjala 2019-01-22 18:13:37 UTC 
(In reply to genpur from comment #19)
> Do I have to clone any branch of "drm-tip" via "git clone ..." ? Or maybe
> download the kernel source, copy some files from
> cgit.freedesktop.org/drm/drm-tip/ , patch the source files  and proceed full
> kernel compilation ...? Could you give me some tips how should I use
> "drm-tip", please? Thank you in advance for help.

Something along these lines:

If you don't have a kernel git repo around then:
git clone git://anongit.freedesktop.org/drm-tip linux
cd linux
git checkout -b your_branch_name origin/drm-tip

Or if you already have one cloned from somewhere else:
cd linux
git remote add drm-tip git://anongit.freedesktop.org/drm-tip
git fetch drm-tip
git checkout -b your_branch_name drm-tip/drm-tip
Comment 21 Lakshmi 2019-02-27 14:00:05 UTC 
Reporter, any updates here? Do you still have the issue?
No feedback for more than a month. Dropping the priority to Medium.
Comment 22 genpur 2019-03-01 22:25:08 UTC 
I am sorry but since January I work on delegation far away from home. The earliest I will be able to check in the Easter.
Comment 23 genpur 2019-04-24 10:41:53 UTC 
> 
> Something along these lines:
> 
> If you don't have a kernel git repo around then:
> git clone git://anongit.freedesktop.org/drm-tip linux
> cd linux
> git checkout -b your_branch_name origin/drm-tip
> 

I have cloned about 2.3GiB of data with commands above. What do I need to do next and how?
Comment 24 Manasi 2019-05-22 23:03:38 UTC 
Now that you have cloned the latest drm-tip, could you check if this bug can be reproduced?

Manasi
Comment 25 ashutosh.dixit 2019-11-21 19:51:44 UTC 
Assessing old bugs, no updates in the last 6 months. Is the problem still there or can we close this? Could you verify with drm tip? If you still need help compiling the kernel please update the bug and we will help.

#assessment
Comment 26 Martin Peres 2019-11-29 17:47:33 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/119.

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.