Bug 16920 - [965GM] HDMI->DVI on Dell XPS M1330 broken by SDVO-HDMI patch in 2.4.0
Summary: [965GM] HDMI->DVI on Dell XPS M1330 broken by SDVO-HDMI patch in 2.4.0
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: 7.3 (2007.09)
Hardware: x86 (IA32) Linux (All)
: medium major
Assignee: Wang Zhenyu
QA Contact: Xorg Project Team
Depends on:
Reported: 2008-07-31 06:44 UTC by Tobias Hain
Modified: 2008-08-06 18:01 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Xorg.0.log_20080731_master_git.log (45.41 KB, text/plain)
2008-07-31 06:45 UTC, Tobias Hain
no flags Details
Xorg.0.log_intel_2_4_0.log (49.76 KB, text/plain)
2008-07-31 06:46 UTC, Tobias Hain
no flags Details
Xorg.0.log_intel_2_3_2.log (59.98 KB, text/plain)
2008-07-31 06:46 UTC, Tobias Hain
no flags Details
xrandr_20080731_master_git.txt (817 bytes, text/plain)
2008-07-31 06:47 UTC, Tobias Hain
no flags Details
xrandr_intel_2_3_2.txt (787 bytes, text/plain)
2008-07-31 06:47 UTC, Tobias Hain
no flags Details
sdvo hdmi mode test (2.06 KB, patch)
2008-08-05 01:53 UTC, Wang Zhenyu
no flags Details | Splinter Review
Xorg.0.log with ModeDebug and patch applied (18.91 KB, text/plain)
2008-08-05 02:53 UTC, Tobias Hain
no flags Details
updated sdvo hdmi mode detect patch (2.66 KB, patch)
2008-08-05 23:43 UTC, Wang Zhenyu
no flags Details | Splinter Review

Description Tobias Hain 2008-07-31 06:44:43 UTC
Operating System : Ubuntu 8.04.1 x86
Platform : 965GM on Dell XPS M1330
kernel : 2.6.24-19-generic (Ubuntu default)
X-Org 7.3 X-server 1.4

upgrading from git xf86-video-intel-2.3-branch b80bf50f8ebfe70044e66c7e8558e3031ba3cfca Bump version 2.3.2
to xf86-video-intel-2.4-branch or to git tip of 31/07/2008
master 76eb8e6f1f0c6962b23550564f4273f392567857 Fix SDVO reg definition
results in a black screen (= no display) on SDVO-HDMI output.

The SDVO HDMI transmitter that is used is this one:

*   SDVO Encoder Report   *
** Encoder 1 **
Vendor ID:      Silicon Image
Device ID:      174
Device Revision:        0
Major Version:  1
Minor Version:  2

. The screen (HP w2408) is attached by means of a DVI/HDMI adapter and detected by xrandr just fine. I can configure it perfectly - it's just the screen that stays black.
. analog VGA output works fine.
. intel 2.3.2 driver works also fine with HDMI.
. libdrm2 is upgraded to version 2.3.1
since I saw that the debian package introduces this dependency (was 2.3.0 before):

Maybe this bug is related to
since I see the same
(EE) intel(0): underrun on pipe A!

Might be as well be related to another 965GM SDVO regression bug in 2.4.0:

I can see you did test SDVO with HDMI on 2.4.0 here:
Comment 1 Tobias Hain 2008-07-31 06:45:55 UTC
Created attachment 18032 [details]
Comment 2 Tobias Hain 2008-07-31 06:46:17 UTC
Created attachment 18033 [details]
Comment 3 Tobias Hain 2008-07-31 06:46:41 UTC
Created attachment 18034 [details]
Comment 4 Tobias Hain 2008-07-31 06:47:02 UTC
Created attachment 18035 [details]
Comment 5 Tobias Hain 2008-07-31 06:47:31 UTC
Created attachment 18036 [details]
Comment 6 Tobias Hain 2008-07-31 08:35:51 UTC
bisecting reveals:

45c1da56891723dd85153853885dd3b52a23c117 is first bad commit
commit 45c1da56891723dd85153853885dd3b52a23c117
Author: Hong Liu <hong.liu@intel.com>
Date:   Fri Jun 20 10:57:14 2008 +0800

    Fix SDVO HDMI output.
    While some cards had enough initialized at startup to work already, others
    required that the driver actually initialize the required AVI info frame.
    (cherry picked from commit 05df8c0b31721a9ccc7215fb1cda1115758367c7)


One more note: If the xserver is started with a bad driver once, then restarting xserver with a good driver will also display no image. You need to reboot the entire machine to get SDVO HDMI output working again.
Comment 7 Gordon Jin 2008-07-31 19:48:25 UTC
Thanks for the bisecting.
It's interesting:
In 2.3.x, we don't have HDMI support, but your machine works.
Hong added the patch into 2.4.0, which makes many people's SDVO-HDMI working (including ours, all are Asus P5E-VM G35 HDMI board), but it makes your machine not work now.

Reassign back to Zhenyu, as Zhenyu has taken this over from Hong.
Comment 8 Wang Zhenyu 2008-08-04 22:25:42 UTC
Does it work if you comment out these two lines?

In src/i830_sdvo.c, i830_sdvo_mode_set() function.

    if (dev_priv->encode.hdmi_rev) 
        i830_sdvo_set_avi_infoframe(output, mode);

Comment 9 Tobias Hain 2008-08-04 23:37:10 UTC
No it does NOT work.

But it works if I comment out these lines:

In src/i830_sdvo.c, i830_sdvo_init() function.

	if (dev_priv->encode.hdmi_rev != 0) {
	    /* enable hdmi encoding mode if supported */
	    i830_sdvo_set_encode(output, SDVO_ENCODE_HDMI);
	    i830_sdvo_set_colorimetry(output, SDVO_COLORIMETRY_RGB256);
	    name_prefix = "HDMI";
Comment 10 Tobias Hain 2008-08-05 01:02:04 UTC
It also works if I just force SDVO_ENCODE_DVI:

diff --git a/src/i830_sdvo.c b/src/i830_sdvo.c
index d9b76d4..9c4d11c 100644
--- a/src/i830_sdvo.c
+++ b/src/i830_sdvo.c
@@ -1845,7 +1845,7 @@ i830_sdvo_init(ScrnInfoPtr pScrn, int output_device)
        i830_sdvo_get_supp_encode(output, &dev_priv->encode);
        if (dev_priv->encode.hdmi_rev != 0) {
            /* enable hdmi encoding mode if supported */
-           i830_sdvo_set_encode(output, SDVO_ENCODE_HDMI);
+           i830_sdvo_set_encode(output, SDVO_ENCODE_DVI);
            i830_sdvo_set_colorimetry(output, SDVO_COLORIMETRY_RGB256);
            name_prefix = "HDMI";

Basically I'm connecting a DVI display (by means of an HDMI/DVI adapter) as you can see from my first post. I don't have a real home entertainment HDMI device such as a TV with HDMI input to cross check.

Since neither SDVO information is available to the public

nor any technical datasheet for the Silicon Image 174 HDMI Transmitter, I really don't know what's the correct transmission mode in this setup.

If DVI displays have to be treated special, then I'd guess you'll find the information that it's a DVI device in some EDID extension.
Comment 11 Tobias Hain 2008-08-05 01:16:27 UTC
It looks like
VESA Display Information Extension Block Standard (DI-EXT) page 14

contains the information: Offset 02h

"02h" --- Digital Visual Interface (DVI) -- Single Link
"05h" --- Digital Visual Interface (DVI) -- For Consumer Electronics
Comment 12 Wang Zhenyu 2008-08-05 01:53:11 UTC
Created attachment 18134 [details] [review]
sdvo hdmi mode test

Could you try this patch to see if driver can correctly detect encoding mode?

Current xserver might lack support for EDID extension, should be added soon.
Comment 13 Tobias Hain 2008-08-05 02:20:27 UTC
Yes this patch works for me. Tested with both:

xf86-video-intel-2.4-branch f3b72c59e5000bcdb07cbdf080e09c55b9826eff
master                      1a59cc6b9acf312de1755d67757bf7f1967342e4

Thanks for your quick submission!
Comment 14 Wang Zhenyu 2008-08-05 02:28:30 UTC
Fine. Could you enable ModeDebug option in xorg.conf and send me X log? so I can review what that new encoding mode command gets back from your device.
Comment 15 Tobias Hain 2008-08-05 02:53:13 UTC
Created attachment 18135 [details]
Xorg.0.log with ModeDebug and patch applied
Comment 16 Wang Zhenyu 2008-08-05 18:08:56 UTC
what's the log file type? seems not text/plain?
Comment 17 Tobias Hain 2008-08-05 23:19:22 UTC
it is .gz (19KB) from 240Kb. That's why I had chosen "application/octet-stream" in the first place.

Let me know if I should readd/replace with .txt version.
Comment 18 Wang Zhenyu 2008-08-05 23:25:58 UTC
Got it. It looks "get encode" command really reads back current mode, 00 is DVI mode, 01 is HDMI mode.

Thanks for test, I'll push this fix to upstream soon.

Comment 19 Wang Zhenyu 2008-08-05 23:43:52 UTC
Created attachment 18148 [details] [review]
updated sdvo hdmi mode detect patch

Could you help to verify this updated patch? I've tested with a HDMI TV and a HDMI-DVI monitor.
Comment 20 Tobias Hain 2008-08-06 00:32:15 UTC
The updated hdmi mode detect patch works also fine here on DVI display.
Comment 21 Wang Zhenyu 2008-08-06 18:01:32 UTC
Patch is pushed, so close.

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.