Bug 50501 - [ilk vga kvm] EDID detection fails thru a KVM switch as it works with vesa driver
Summary: [ilk vga kvm] EDID detection fails thru a KVM switch as it works with vesa dr...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Daniel Vetter
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-30 05:35 UTC by Matthieu
Modified: 2017-07-24 23:01 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
The Xorg log with the nomodeset option and connected to the KVM (79.81 KB, text/plain)
2012-05-30 05:35 UTC, Matthieu
no flags Details
The Xorg log while booting normally connected to the switch (edid fail) (21.56 KB, text/plain)
2012-05-30 05:37 UTC, Matthieu
no flags Details
The Xorg log with screen directly connected (no switch) (44.03 KB, text/plain)
2012-05-30 05:38 UTC, Matthieu
no flags Details
dmesg with drm.debug=6 (88.61 KB, text/plain)
2012-05-30 08:21 UTC, Matthieu
no flags Details
dmesg log with Disabled hotplug and drm.debug=6 (135.10 KB, application/octet-stream)
2012-05-31 01:48 UTC, Matthieu
no flags Details
The Xorg log while booting normally connected to the switch and hotplug disabled (edid success) (41.29 KB, application/octet-stream)
2012-05-31 01:49 UTC, Matthieu
no flags Details
Do not rely on HPD (1.25 KB, patch)
2012-05-31 02:19 UTC, Chris Wilson
no flags Details | Splinter Review
the dmesg log with patch and drm.debug=6 (146.57 KB, application/octet-stream)
2012-05-31 05:07 UTC, Matthieu
no flags Details
The Xorg log while booting normally connected to the switch and patch applied (edid success) (43.81 KB, application/octet-stream)
2012-05-31 05:08 UTC, Matthieu
no flags Details
only try the edid detction, not load detect as a fallback (2.54 KB, patch)
2012-06-10 10:09 UTC, Daniel Vetter
no flags Details | Splinter Review
the dmesg log with the last patch and drm.debug=6 (139.09 KB, application/octet-stream)
2012-06-11 00:20 UTC, Matthieu
no flags Details
The Xorg log while booting normally connected to the switch and last patch applied (edid success) (41.30 KB, application/octet-stream)
2012-06-11 00:21 UTC, Matthieu
no flags Details

Description Matthieu 2012-05-30 05:35:57 UTC
Created attachment 62285 [details]
The Xorg log with the nomodeset option and connected to the KVM

The goal is to use my computer with an KVM switch, and the switch seems to block EDID detection of the screen for the intel driver. The detection works with the vesa driver (nomodeset krnl opt) and I don't have this problem with my other computer (one is an intel 945G IGP(MB Atom D945DCLF) running Ubuntu 10.04).

Here is my configuration :
 - Core I3 2125 (IGP HD3000)
 - ASRock H61M-ITX
 - Screen Samsung Syncmaster T200
 - KVM Switch Trendnet TK-408.
 - Ubuntu 12.04, but same trouble with last fedora and linux mint.

It's not an hardware problem as the detection works well with the vesa driver, but not with the intel one.
Comment 1 Matthieu 2012-05-30 05:37:32 UTC
Created attachment 62286 [details]
The Xorg log while booting normally connected to the switch (edid fail)
Comment 2 Matthieu 2012-05-30 05:38:40 UTC
Created attachment 62287 [details]
The Xorg log with screen directly connected (no switch)
Comment 3 Chris Wilson 2012-05-30 05:42:12 UTC
Can you also please attach the drm.debug=6 dmesg when booting normally connected to the KVM?
Comment 4 Matthieu 2012-05-30 08:21:05 UTC
Created attachment 62292 [details]
dmesg with drm.debug=6
Comment 5 Chris Wilson 2012-05-30 12:59:10 UTC
This seems to be a hardware issue where the HPD pin of the KVM is not wired up:

[   20.084953] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:5:VGA-1]
[   20.084957] [drm:intel_ironlake_crt_detect_hotplug], trigger hotplug detect cycle: adpa=0xf40008
[   20.099937] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug adpa=0xf40008, result 0
[   20.099943] [drm:intel_crt_detect], CRT not detected via hotplug
[   20.099947] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:5:VGA-1] disconnected
Comment 6 Chris Wilson 2012-05-30 13:00:12 UTC
Try disabling hotplug detection for CRT:

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index f0223d0..43d4130 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -452,7 +452,7 @@ intel_crt_detect(struct drm_connector *connector, bool force
        enum drm_connector_status status;
        struct intel_load_detect_pipe tmp;
 
-       if (I915_HAS_HOTPLUG(dev)) {
+       if (0) {
                if (intel_crt_detect_hotplug(connector)) {
                        DRM_DEBUG_KMS("CRT detected via hotplug\n");
                        return connector_status_connected;
Comment 7 Matthieu 2012-05-31 00:02:14 UTC
(In reply to comment #5)
> This seems to be a hardware issue where the HPD pin of the KVM is not wired up:
> 
> [   20.084953] [drm:drm_helper_probe_single_connector_modes],
> [CONNECTOR:5:VGA-1]
> [   20.084957] [drm:intel_ironlake_crt_detect_hotplug], trigger hotplug detect
> cycle: adpa=0xf40008
> [   20.099937] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug
> adpa=0xf40008, result 0
> [   20.099943] [drm:intel_crt_detect], CRT not detected via hotplug
> [   20.099947] [drm:drm_helper_probe_single_connector_modes],
> [CONNECTOR:5:VGA-1] disconnected

I'm ok for the missing pin, but there is a miss in the driver as with the same hardware configuration, the VESA driver correctly detect and gets edid data.
And the Intel driver of my other computer also correctly detect it throught the KVM.
Comment 8 Matthieu 2012-05-31 01:47:12 UTC
(In reply to comment #6)
> Try disabling hotplug detection for CRT:
> 
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index f0223d0..43d4130 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -452,7 +452,7 @@ intel_crt_detect(struct drm_connector *connector, bool
> force
>         enum drm_connector_status status;
>         struct intel_load_detect_pipe tmp;
> 
> -       if (I915_HAS_HOTPLUG(dev)) {
> +       if (0) {
>                 if (intel_crt_detect_hotplug(connector)) {
>                         DRM_DEBUG_KMS("CRT detected via hotplug\n");
>                         return connector_status_connected;

It works, Thanks. 
I'll join Xorg and dmesg log.
Is there a configuration way to disable Hotplug, instead of compilation ?
Comment 9 Matthieu 2012-05-31 01:48:31 UTC
Created attachment 62317 [details]
dmesg log with Disabled hotplug and drm.debug=6
Comment 10 Matthieu 2012-05-31 01:49:28 UTC
Created attachment 62318 [details]
The Xorg log while booting normally connected to the switch and hotplug disabled (edid success)
Comment 11 Chris Wilson 2012-05-31 02:19:45 UTC
Created attachment 62319 [details] [review]
Do not rely on HPD

Can you please try this patch and if happy please reply with a Tested-by: My name <my email>?
Comment 12 Matthieu 2012-05-31 05:03:11 UTC
(In reply to comment #11)
> Created attachment 62319 [details] [review] [review]
> Do not rely on HPD
> 
> Can you please try this patch and if happy please reply with a Tested-by: My
> name <my email>?

Tested-by: Matthieu LAVIE.
Comment 13 Matthieu 2012-05-31 05:06:22 UTC
As I'm a noob, I don't know how to apply the patch. So I've apply the patch by hand, to have this function:

intel_crt_detect(struct drm_connector *connector, bool force)
{
	struct drm_device *dev = connector->dev;
	struct intel_crt *crt = intel_attached_crt(connector);
	struct drm_crtc *crtc;
	enum drm_connector_status status;

	if (I915_HAS_HOTPLUG(dev)) {
		if (intel_crt_detect_hotplug(connector)) {
			DRM_DEBUG_KMS("CRT detected via hotplug\n");
			return connector_status_connected;
		} else 
			DRM_DEBUG_KMS("CRT not detected via hotplug\n");
	}

	if (intel_crt_detect_ddc(connector))
		return connector_status_connected;

I works well.

I'll post dmesg with drm.debug=6 and Xorg.
In dmesg we found that:
May 31 13:51:54 Ub12 kernel: [   28.514947] [drm:intel_crt_detect], CRT not detected via hotplug
May 31 13:51:54 Ub12 kernel: [   28.584350] [drm:intel_crt_detect_ddc], CRT detected via DDC:0x50 [EDID]

Thanks for your help.
Matthieu
Comment 14 Matthieu 2012-05-31 05:07:13 UTC
Created attachment 62333 [details]
the dmesg log with patch and drm.debug=6
Comment 15 Matthieu 2012-05-31 05:08:00 UTC
Created attachment 62334 [details]
The Xorg log while booting normally connected to the switch and patch applied (edid success)
Comment 16 Chris Wilson 2012-05-31 05:10:42 UTC
The trick would be to use 'git am -3 < /path/to/patch'. Though, that would have actually depended upon having my parent commit, so you might have had to resort just to using 'patch -p1 < /path/to/patch'

Anyway, you reconstructed the required changes, so all is well :)
Comment 17 Daniel Vetter 2012-05-31 06:05:50 UTC
Patch merged to drm-intel-fixes as:

commit 9e612a008fa7fe493a473454def56aa321479495
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu May 31 13:08:53 2012 +0100

    drm/i915/crt: Do not rely upon the HPD presence pin
Comment 18 Chris Wilson 2012-06-10 02:04:20 UTC
Patch was rejected because Linus disapproved of the behvaiour of userspace when faced with an unknown connection. So in order to get KVMs to work we have to first fix the existing handling of indeterminate results...
Comment 19 Matthieu 2012-06-10 09:38:13 UTC
Thanks for your feedback, I'll follow the advancement of this bug.
Comment 20 Daniel Vetter 2012-06-10 10:09:55 UTC
Created attachment 62862 [details] [review]
only try the edid detction, not load detect as a fallback

New patch, please test whether detection of your monitor-behind-a-kvm still works.
Comment 21 Matthieu 2012-06-11 00:18:10 UTC
(In reply to comment #20)
> Created attachment 62862 [details] [review] [review]
> only try the edid detction, not load detect as a fallback
> 
> New patch, please test whether detection of your monitor-behind-a-kvm still
> works.

Yes it works. The logs will follow.
Comment 22 Matthieu 2012-06-11 00:20:36 UTC
Created attachment 62868 [details]
the dmesg log with the last patch and drm.debug=6
Comment 23 Matthieu 2012-06-11 00:21:15 UTC
Created attachment 62869 [details]
The Xorg log while booting normally connected to the switch and last patch applied (edid success)
Comment 24 Daniel Vetter 2012-06-20 01:10:31 UTC
New patch merged to -next-queued as

commit aaa377302b2994fcc2c66741b47da33feb489dca
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Jun 16 15:30:32 2012 +0200

    drm/i915/crt: Do not rely upon the HPD presence pin

I've tried to push this through -fixes, but got shot at for trying. So this will only land in 3.6
Comment 25 Florian Mickler 2012-07-02 01:08:08 UTC
A patch referencing a commit referencing this bug report has been merged in Linux v3.5-rc2:

commit 8f53369b753f5f4c7684c2eb0b592152abb1dd00
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Jun 8 14:53:06 2012 -0700

    Revert "drm/i915/crt: Do not rely upon the HPD presence pin"
Comment 26 Matthieu 2012-07-04 00:25:25 UTC
(In reply to comment #25)
> A patch referencing a commit referencing this bug report has been merged in
> Linux v3.5-rc2:
> 
> commit 8f53369b753f5f4c7684c2eb0b592152abb1dd00
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Fri Jun 8 14:53:06 2012 -0700
> 
>     Revert "drm/i915/crt: Do not rely upon the HPD presence pin"

This is the revert made by Linus the 6th of june because it errornously detected a vga
screen (without and edid and hence only the default modes).

The new patch will arrive with the 3.6. (merged by Daniel Vetter the 20th of june) See comment 24.
Comment 27 Florian Mickler 2012-08-05 11:29:45 UTC
A patch referencing a commit referencing this bug report has been merged in Linux v3.6-rc1:

commit a2bd1f541f1990dda7dd62f190342c9a964ceb4f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Jul 11 12:31:52 2012 +0200

    drm/i915: check whether we actually received an edid in detect_ddc


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.