Created attachment 23447 [details] ModeDebug on. Only HDMI connected. chipset: GM965 architecture: i686 xorg driver: git-tip drm: packaged with 2.6.27.16-78 (fc9 repo) libdrm: git kernel 2.6.27.15-78 distro: fc9 I have a DE965-HG machine made by Aopen with two VGA ports and an HDMI port. On boot, the hdmi connection is detected and the console operates as expected. Using the latest driver, X starts without error. The logs show the connection being detected and EDID being read. The correct resolution is detected. xrandr shows that the output is connected and operational but there is no signal being received by the monitor. Stopping X, brings back the text console. Also, one of the vga ports is being incorrectly identified as output TV-1. Four outputs are detected by xrandr: VGA, TV-1, TMDS-2 and TV (which has the usual TV parameters, but no port is available on the back panel of the machine). I'm not sure if there is anything that can be done about this, but the information is here. A further bit of information: using the iegd 9.0.2 driver, hdmi output is available in X using an SDVO port. Attached is an xorg.0.log with ModeDebug on. Only the hdmi cable is attached.
zhenyu should have a look at this: - Multi-caps SDVO device support. See showing as TV-1 when no connection confuses user... - why detected as TMDS-2 rather than HDMI-2 (Alex, you didn't use a HDMI-DVI converter,right?) - TV detection from BDB? though low priority...
pls attach you vbios rom. you can get it via: # cd /sys/devices/pci0000\:00/0000\:00\:02.0/ # echo 1 > rom # cat rom > /tmp/rom.bin # echo 0 > rom then attach the rom.bin thanks.
Could you try to disable TV in xorg.conf? like below, Section "Monitor" Identifier "TV" Option "Ignore" "true" EndSection Section "Device" Identifier "Intel gfx" Driver "intel" .... Option "monitor-TV" "TV" EndSection
Created attachment 23470 [details] VBIOS dump on DE965-HG Machine
Created attachment 23471 [details] Xorg.0.log with TV output disabled Attached is an Xorg log when starting with the TV output disabled as recommended. Behavior appears the same as before.
The TV issue should be a hw/fw bug - it doesn't build any TV connector out but still claim TV supported in the FW. anyway, it's shown as disconnected, so should not be a problem. this is: (EE) intel(0): First SDVOC output reported failure to sync
Have you tried if other mode lines could work?
also, what if you connect monitor to the VGA port connected to SDVO? you might need to try more than once to figure out. In xrandr , it's called VGA-1. thanks.
(In reply to comment #7) > Have you tried if other mode lines could work? > Hello. I tried every modeline available on HDMI output today and none of them showed any signal when only hdmi was connected.
(In reply to comment #8) > also, what if you connect monitor to the VGA port connected to SDVO? you might > need to try more than once to figure out. In xrandr , it's called VGA-1. > thanks. > When a monitor is connected to the second VGA port, the TV-1 output changes to VGA-1 in xrandr. If only the VGA-1 is connected (no VGA and HDMI-2), then symptoms similar to when only HDMI-1 is connected appear, i.e., xrandr --prop shows the monitor connected, edid data and a supported mode being used but no signal is present on the monitor. Now if both VGA-1 and HDMI-2 are connected, output is shown on the VGA-1 monitor, and the HDMI-1 connected monitor shows 'Mode not supported'. I can freely adjust modes on both outputs through xrandr but I can never get the HDMI to output a mode that is 'supported'. At some point during experimenting, the HDMI-2 picked up the signal correctly and showed the X desktop. A combination of VGA-1 and HDMI-2 unplugs/replugs and X server restarts yielded that result, but I have been unable to reproduce thus far.
Are there any other tests that I can help with ?
Created attachment 24454 [details] please try the patch on your machine ,then upload log file with modedebug option on, thanks the log in comment #5 shows 1) bios enable sdvob port, but driver enable sdvoc 2) (II) intel(0): SDVOB: W: 02 (SDVO_CMD_GET_DEVICE_CAPS) (II) intel(0): SDVOB: R: 02 42 02 01 01 3D 3E 00 (Success) doesn't find right capability, So please try the patch under comment #5 environment. thanks Ma Ling
Created attachment 24508 [details] xorg.0.log - git-head patched with patch 20429_debug.patch This bug currently allows hdmi to be output correctly on an Aopen DE965HG machine.
(In reply to comment #12) > Created an attachment (id=24454) [details] > please try the patch on your machine ,then upload log file with modedebug > option on, thanks > > the log in comment #5 shows > 1) bios enable sdvob port, but driver enable sdvoc > 2) (II) intel(0): SDVOB: W: 02 (SDVO_CMD_GET_DEVICE_CAPS) > (II) intel(0): SDVOB: R: 02 42 02 01 01 3D 3E 00 (Success) > doesn't find right capability, > So please try the patch under comment #5 environment. > > thanks > Ma Ling > Patch was successful in solving the problem described.(In reply to comment #12) > Created an attachment (id=24454) [details] > please try the patch on your machine ,then upload log file with modedebug > option on, thanks > > the log in comment #5 shows > 1) bios enable sdvob port, but driver enable sdvoc > 2) (II) intel(0): SDVOB: W: 02 (SDVO_CMD_GET_DEVICE_CAPS) > (II) intel(0): SDVOB: R: 02 42 02 01 01 3D 3E 00 (Success) > doesn't find right capability, > So please try the patch under comment #5 environment. > > thanks > Ma Ling > (In reply to comment #13) > Created an attachment (id=24508) [details] > xorg.0.log - git-head patched with patch 20429_debug.patch > > This bug currently allows hdmi to be output correctly on an Aopen DE965HG > machine. > The patch also allows for TMDS output via HDMI port using an HDMI->DVI cable.
Created attachment 24960 [details] hi Alexander Ho, please try the debug patch on your machine, thanks. hi Alexander Ho, This is a general debug patch, which intends dynamically to assign sdvo slave addr-0x70 or 0x72 to SDVB or SDVOC. After running please upload your log file with modedebug option on after. thanks maling
Created attachment 24978 [details] Xorg log using git-head with patch 24960 applied The driver was successful in setting up the HDMI display using HDMI->HDMI cable and also HDMI->DVI.
Created attachment 25213 [details] please try the debug patch on your machine, thanks. please try the patch on your machine, then upload log file with modedebug option on. thanks maling
ping ~
Created attachment 25561 [details] Xorg log with patch 25213 using HDMI Sorry for the late reply! Driver with this patch applied does not successfully initialize the HDMI display. Also, the display was not returned when switching back to the terminal nor when stopping X. Under the same environment, patch (id 24960) successfully initialized the HDMI display.
Created attachment 25562 [details] Xorg log with patch 25213 using HDMI Sorry for the late reply! Driver with this patch applied does not successfully initialize the HDMI display. Also, the display was not returned when switching back to the terminal nor when stopping X. Under the same environment, patch (id 24960) successfully initialized the HDMI display.
Created attachment 26214 [details] [review] [Patch 1/4]: dynamically get the number of chid device in general definition blocks
Created attachment 26215 [details] [review] [Patch 2/4]: parse the general definition block to get the SDVO device info
Created attachment 26216 [details] [review] [patch 3/4]: add a function that find a slave address for one SDVO port
Created attachment 26217 [details] [review] [patch 4/4]: initialize the SDVO device based on the valid slave address
Hi, Alexander Will you please try the attached patch set in comment #21-#24 and see whether the issue can be fixed? It will be great if you can attach the output of xorg log. Thanks.
The attached patch set can fix the issue in this bug. And is is already committed in the latest intel driver. At the same time it is also shipped in KMS mode. So this bug will be marked as resolved. thanks.
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.