|Summary:||[snb hdmi tv] Xorg unable to correctly display though HDMI on Intel Biostar TZ77A|
|Component:||DRM/Intel||Assignee:||Daniel Vetter <daniel>|
|Status:||CLOSED FIXED||QA Contact:|
|Priority:||medium||CC:||ben, chris, daniel, jbarnes|
|i915 platform:||i915 features:|
Description earthwormgaz 2012-05-10 12:18:59 UTC
Hi, I have a new PC, with a Biostar TZ77A board in it, it's Intel 1155 based. It has a HDMI port which I've plugged into my Wharfdale TV ... Wharfedale LCD37F1080P 37in 1080p HD Ready Digital LCD TV. Television Picture Quality 1080p High Definition Ready. Integrated digital (freview). 37in (94cm) widescreen TV with 93cm visible screen size. Resolution 1920 x 1080 pixels. Brightness 500 cd/m2. Contrast 1600:1. Viewing angle 178/178 degrees. Progressive scan. Connectivity 2 HDMI sockets http://reviews.argos.co.uk/1493-en_gb/5364040/reviews.htm HDMI works fine through my PS3. On my Fedora 17 machine (all updates applied), the BIOS and Grub can be seen, but when X starts to show Plymouth, I get a black screen, then when the log in screen should be on the TV, I see a blue screen. Output works fine through normal VGA. I've tried using xrandr to change resolution, but nothing autoconfigured seems to work, I end up with either a black screen or a blue screen. I'll attach some log files. I tried doing Xorg :0 -configure to dump a config I could bodge into working, but that gives me ... Number of created screens does not match number of detected devices. Configuration failed. Server terminated with error (2). Closing log file.
Comment 3 earthwormgaz 2012-05-10 12:23:11 UTC
So you can see in the Xorg log it thinks it has autodetected everything fine, yet there is nothing on the HDMI output.
Comment 4 Chris Wilson 2012-05-10 12:33:10 UTC
The first step would be a drm.debug=6 (append that to your kernel boot parameters) dmesg. I notice that the TV is advertising interlaced/doublescan modes, so we may handle this better with a recent kernel, and it probably will turn out to be a CEA issue...
Comment 5 earthwormgaz 2012-05-10 13:10:29 UTC
Kernel version is three point three point four.
Comment 6 Chris Wilson 2012-05-10 13:13:57 UTC
As I was saying, around here 3.3.4 is quite old ;-)
Comment 7 earthwormgaz 2012-05-10 13:49:25 UTC
Created attachment 61401 [details] dmesg.drm.debug.out
Comment 8 earthwormgaz 2012-05-10 13:50:48 UTC
Oh right. I wonder if there's newer in Fedora testing? Has that new attachment got the extra logging in it?
Comment 9 earthwormgaz 2012-05-10 13:55:07 UTC
kernel-3.3.4-5.fc17.x86_64.rpm seems to be the latest. Probably not a great deal newer.
Comment 10 earthwormgaz 2012-05-10 23:53:52 UTC
Is this against the right component?
Comment 11 Chris Wilson 2012-05-11 06:41:19 UTC
(In reply to comment #10) > Is this against the right component? We use DRI/Intel as our catchall for kernel bugs. And nowadays modesetting is controlled by the kernel, ergo this is the right component.
Comment 12 Chris Wilson 2012-05-31 08:25:37 UTC
Do you have a 3.4 kernel available for testing yet? Though there are still more relevant bits pending for 3.5.
Comment 13 earthwormgaz 2012-06-02 02:06:52 UTC
I'll be honest, I had to drop back to Fedora 16 because I couldn't even get the Gnome Desktop to work (another bug filed against Gnome), having fallen back to video out through VGA. 3.3.7-1.fc16.x86_64 is the latest on F16. I found this bug report saying 3.4.1 will be on F16 and 17. Is that far off?
Comment 14 earthwormgaz 2012-06-02 02:18:24 UTC
http://forums.fedoraforum.org/showthread.php?t=280324 That doesn't sound promising either, when is 3.4.1 out?
Comment 15 Chris Wilson 2012-06-02 02:25:42 UTC
3.4.1 is in the final review stage before release; so not too long.
Comment 16 earthwormgaz 2012-06-18 14:53:49 UTC
Now running 3.4.2 I think on Fedora 16, rebooted into it and no HDMI output. Do I need to collect logs again etc?
Comment 17 Daniel Vetter 2012-06-19 01:28:36 UTC
Ok, a few things to try: - If your screen has a DVI input, please try to connect it through that (you might need a HDMI->DVI cable for that). - What happens when you try different resolutions/refresh rates? According to the logs we detect the HDMI screen with its modes, so maybe it's only an issue with the default. - This could be an infoframe issue and we've recently fixed quite a few of these. Can you please try to run the latest drm-intel-next-queued branch from the drm-intel git repo at: http://cgit.freedesktop.org/~danvet/drm-intel
Comment 18 earthwormgaz 2012-06-27 14:18:18 UTC
Ah ha, I noodled about with Gnome display settings, and this NOW WORKS, with 3.4.2 I think it is! HDMI working, with sound to boot, and MythTV looks loads better!
Comment 19 Daniel Vetter 2012-06-28 02:10:33 UTC
Just to check: If you boot, hdmi still doesn't work, but after frobbing a bit with gnome settings, it works now? Can you please attach the output of xrandr --verbose for both the broken and the working configuration?
Comment 20 earthwormgaz 2012-06-28 07:04:17 UTC
So, reboot with the old kernel and attach the logs? I looked at Gnome display settings, and saw there was another monitor, I enabled it, and the settings looked like HD settings, so I set it to 1080p and swapped to HDMI and it was working. I did notice after posting that that the picture is going off the edge of the screen a bit, so I can only half see the MythTV clock at the bottom for example. I will try and add those attachments later or something.
Comment 21 Daniel Vetter 2012-06-28 07:10:56 UTC
> --- Comment #20 from firstname.lastname@example.org 2012-06-28 07:04:17 PDT --- > So, reboot with the old kernel and attach the logs? Yeah. > I looked at Gnome display settings, and saw there was another monitor, I > enabled it, and the settings looked like HD settings, so I set it to 1080p and > swapped to HDMI and it was working. Hm, I guess that xrandr --verbose output might be rather interesting indeed. > I did notice after posting that that the picture is going off the edge of the > screen a bit, so I can only half see the MythTV clock at the bottom for > example. Smells like overscan compenstation. Atm our HDMI infoframe support isn't stellar, so the TV assumes the defaults, which for many modes is using some overscan compensation (a relict from analog TV). Separate bug.
Comment 22 Daniel Vetter 2012-08-22 10:55:46 UTC
We've fixed up our snb infoframe support a lot in 3.6-rc (the overscan compensation is not implement yet, but that's a different beast, more feature than bug, really). I'll presume this is fixed, thanks for reporting the bug, but please reopen if it doesn't work on 3.6.