Bug 496772 - hdmi output not working with G33 chipset
Summary: hdmi output not working with G33 chipset
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel
Version: 11
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-21 04:20 UTC by Mike McLean
Modified: 2018-04-11 10:27 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-06-28 12:07:57 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Xorg log (83.12 KB, text/plain)
2009-04-21 04:22 UTC, Mike McLean
no flags Details
Xorg.0.log (221.21 KB, application/octet-stream)
2009-05-03 01:43 UTC, Mike McLean
no flags Details
xorg log from working system (Ubuntu 9.04 live image) (43.98 KB, text/plain)
2009-05-18 20:08 UTC, Mike McLean
no flags Details

Description Mike McLean 2009-04-21 04:20:41 UTC
Description of problem:
I have a new Shuttle SG33G5 system that I'm trying to connect to my hdtv using the hdmi output. While the hdmi display works during boot, it stops as soon as X comes into play. I've tried a number of video modes and gotten nothing.

I know that the hdmi input on the tv works. I normally run my dvd player through it. Additionally, I was able to drive this input using the DVI output on my laptop and a dvi-to-hdmi adapter.

If I use an hdmi-to-dvi adaptor on the SG33G5 system and run it to a DVI monitor, it works like a charm. However, I note that in this case xrandr reports the output as DVI1 (when connected to the tv it reports it as HDMI1). I'm not sure how it tells the difference, but apparently it does.

I have several Xorg logs if you'd like to have a look, but I'm not sure if there's anything helpful in them. It looks like the system is getting a null EDID response from the hdmi output.

I tried turning on ModeDebug, but it doesn't seem to tell me much more.

Version-Release number of selected component (if applicable):
F11 Snap1

Comment 1 Mike McLean 2009-04-21 04:21:31 UTC
I realize this is an odd setup. Any help or pointers would be greatly appreciated.

Comment 2 Mike McLean 2009-04-21 04:22:44 UTC
Created attachment 340475 [details]
Xorg log

Comment 3 Mike McLean 2009-04-21 04:24:22 UTC
Note that in the log I also had a vga output connected so I could see what I was doing.

Comment 4 Adam Jackson 2009-04-23 19:25:40 UTC
HDMI outputs had buggy EDID in snap1, iirc.  kernel-2.6.29.1-102.fc11 and newer should have it fixed?

Comment 5 Mike McLean 2009-05-03 01:37:20 UTC
Well, there is more sensible looking EDID output in the Xorg log now, but still no picture on the tv, nor any sort of reaction.

I'll attach the new log. I tried both probed modes, as well as a 1280x720 mode that I've used successfully on this this tv before.

Comment 6 Mike McLean 2009-05-03 01:43:53 UTC
Created attachment 342201 [details]
Xorg.0.log

Comment 7 Mike McLean 2009-05-03 01:45:17 UTC
I'd be more than happy to try to debug this a little deeper but I'm not sure where else to poke.

Comment 8 Mike McLean 2009-05-15 17:03:17 UTC
Just a data point. I've replicated with a different hdmi television. This one gives me the helpful diagnostic "Not Support!" ;)

Comment 9 Mike McLean 2009-05-18 20:04:26 UTC
Another data point. The hdmi out works with an Ubuntu 9.04 live image. Doesn't quite get the video modes right, but at least it gets me something.
They seem to have:
xserver-xorg-video-intel-2:2.6.3-0ubuntu9
xserver-xorg-1:7.4~5ubuntu18
kernel 2.6.28-11-generic
Will attach the working Xorg log shortly

Comment 10 Mike McLean 2009-05-18 20:08:01 UTC
Created attachment 344514 [details]
xorg log from working system (Ubuntu 9.04 live image)

Comment 11 Mike McLean 2009-05-20 21:10:04 UTC
Apparently the answer is: disable KMS
Booting with nomodeset seems to resolve the problem. I guess that makes this a kernel bug.

Comment 12 Bug Zapper 2009-06-09 14:16:13 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 14 Matěj Cepl 2009-11-05 18:27:22 UTC
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command

yum upgrade --enablerepo='*-updates-testing'

Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

Comment 15 Mike McLean 2009-11-06 21:27:36 UTC
Since this is worked around by nomodeset it may be a kernel bug. The system in question has been working happily with nomodeset on F-11 for months now.

I hope to have a chance to try out an F12 live image on it sometime next week.

Comment 16 Bug Zapper 2010-04-27 13:50:11 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 17 Bug Zapper 2010-06-28 12:07:57 UTC
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.