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 http://packages.ubuntu.com/intrepid/libdrm2 since I saw that the debian package introduces this dependency (was 2.3.0 before): http://packages.debian.org/experimental/xserver-xorg-video-intel Maybe this bug is related to https://bugs.freedesktop.org/show_bug.cgi?id=16833 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: https://bugs.freedesktop.org/show_bug.cgi?id=16638 I can see you did test SDVO with HDMI on 2.4.0 here: https://bugs.freedesktop.org/show_bug.cgi?id=16903#c6
Created attachment 18032 [details] Xorg.0.log_20080731_master_git.log
Created attachment 18033 [details] Xorg.0.log_intel_2_4_0.log
Created attachment 18034 [details] Xorg.0.log_intel_2_3_2.log
Created attachment 18035 [details] xrandr_20080731_master_git.txt
Created attachment 18036 [details] xrandr_intel_2_3_2.txt
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.
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.
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);
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"; }
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 http://softwarecommunity.intel.com/isn/Community/en-US/forums/thread/28280007.aspx 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.
It looks like VESA Display Information Extension Block Standard (DI-EXT) page 14 http://www.vesa.org/Public/EDID%20EXTENSIONS/DIEXT.pdf contains the information: Offset 02h "02h" --- Digital Visual Interface (DVI) -- Single Link "05h" --- Digital Visual Interface (DVI) -- For Consumer Electronics
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.
Yes this patch works for me. Tested with both: xf86-video-intel-2.4-branch f3b72c59e5000bcdb07cbdf080e09c55b9826eff master 1a59cc6b9acf312de1755d67757bf7f1967342e4 Thanks for your quick submission!
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.
Created attachment 18135 [details] Xorg.0.log with ModeDebug and patch applied
what's the log file type? seems not text/plain?
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.
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.
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.
The updated hdmi mode detect patch works also fine here on DVI display.
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.