Bug 50371

Summary:	[BISECTED] HDMI display blank unless VIC set in AVI infoframe
Product:	Drivers	Reporter:	Jon Burgess (jburgess777)
Component:	Video(DRI - Intel)	Assignee:	Paulo Zanoni (przanoni)
Status:	RESOLVED CODE_FIX
Severity:	normal	CC:	alan, daniel, florian, intel-gfx-bugs, przanoni
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:		Subsystem:
Regression:	Yes	Bisected commit-id:
Attachments:	infoframes output, EDID and VIC test results Minimal patch to set the VICs dmesg output with patch applied xrandr --verbose with direct attachment of HMDI2 to TV xrandr --verbose with direct attachment of HMDI2 to TV xrandr --verbose with HDMI2 -> AV -> TV xrandr --verbose with HDMI2 -> AV -> (no TV)

Description Jon Burgess 2012-11-11 16:18:38 UTC

I have a TV connected to my PC via an AV receiver over HDMI. This was working fine until linux-3.5 when it no longer displayed any video. Since 3.5 the display was still detected OK but no output ever appeared on the screen.

Bisection identified commit 4e89ee174bb2da341bf90a84321c7008a3c9210d as the trigger for the issue. The problem seems to be similar to bug 46761 but even with git HEAD 3.7-rc4+ my display still is not working. I then tried a few experiments by tweaking the code and with the intel_infoframes utility.

The root of the problem seems to be the interaction with my AV receiver (Yamaha RX-V767). In older kernels (e.g. 3.4) the AVI infoframes are missing and the receiver seems to work OK with this. Since 3.5+ the kernel is generating AVI infoframes by default and the AV receiver isn't happy with the contents.

If I plug the HDMI cable directly into the TV then it works OK.

I can make the AV receiver happy by either turning off the infoframes:

# intel_infoframes -t B -f AVI -n 

Or by setting the VIC field. The ideal mode for me is 1920x1080p@50Hz which is VIC 31 which I set via:

# intel_infoframes -t B -f AVI -c 'VIC 1f'

note: the hex 1f since the code surprisingly uses scanf(%x)

The graphics are from the integrated GPU in an Intel Core i5 650. Let me know if you want any debug logs etc.

Comment 1 Paulo Zanoni 2012-11-13 12:33:44 UTC

Hi

What happens if you use intel_infoframes to set the VIC to 0 instead of 1f? Does it work? What happens if you use another value?

Can you please attach the output of "intel_infoframes -d" when the screen is black and then after you set the VIC to 1f (or to 0, in case this works).

The HDMI spec says we don't really need to set the VIC, the "0" value should work fine on all cases. I really hope your device is not requiring a VIC since not all modes have non-zero VICs... My guess is that one of the side-effects of setting the VIC value is solving the bug for you.

Thanks,
Paulo

Comment 2 Paulo Zanoni 2012-11-13 12:34:25 UTC

Reassigning bug to me.

Comment 3 Jon Burgess 2012-11-13 23:31:54 UTC

Created attachment 86351 [details]
infoframes output, EDID and VIC test results

> What happens if you use intel_infoframes to set the VIC to 0 instead of 1f?

The TV screen goes blank. 

> Does it work? What happens if you use another value?

The attached document describes what happens. For several VIC settings the TV displays the Linux video perfectly (i.e. 1080p@50Hz). The evidence suggests that the TV itself completely ignores the VIC.

> Can you please attach the output of "intel_infoframes -d" when 
> the screen is black and then after you set the VIC to 1f (or to 
> 0, in case this works).

Output attached for 0 & 1f cases. It also has other information like the EDID.

The output blanks as soon as VIC 0 is specified and returns to normal at VIC 1f. Both of these were from a Fedora 3.6.3-1.fc17.x86_64 kernel but I saw exactly the same behaviour from Linux-3.7-rc4+ over the weekend.

> The HDMI spec says we don't really need to set the VIC, 
> the "0" value should work fine on all cases. I really hope your
> device is not requiring a VIC since not all modes have non-zero
>  VICs... My guess is that one of the side-effects of
> setting the VIC value is solving the bug for you.

I can easily believe that the problem with handling VIC0 is a bug in the AV receiver.

I don't think this is a side effect. I can reliably switch between working an non-working states by setting the VIC.

I thought the spec said that 0 should only be used for modes which don't have a defined VIC. 

On the other hand it also seems to say the sink should ignore the VIC if it conflicts with the format found in the video data stream. 

I started looking through all the modes supported in the EDID and picked one  without an obvious VIC code: 

$ xrandr --output HDMI2 --mode 1280x1024 --rate 75

If VIC is set to 0 (as it probably should be) then I see no output. If I pick VIC4 (1280x720p@60Hz) then I get a valid display. What VIC is chosen doesn't seem to matter too much to the receiver, it seems to pass-through the signal if it thinks it might be supported. The TV seems to ignore the VIC and detect the stream format.

Comment 4 Paulo Zanoni 2012-11-14 12:42:37 UTC

Thanks for the detailed explanation! It really helps debugging!

I can write a patch that sets the VIC value, but not all modes have VICs, so for some modes the value will still be 0. This won't really solve all your problems. Still, I guess this patch can't hurt us.

I'm starting to think about not sending infoframes at all or adding some kind of quirk for those intermediate devices...

Do you lose some kind of feature when you turn the infoframes off? Maybe sound?

Comment 5 Jon Burgess 2012-11-14 21:56:52 UTC

> I can write a patch that sets the VIC value, but not all modes 
> have VICs, so for some modes the value will still be 0. This won't
> really solve all your problems. Still, I guess this patch can't hurt us.

I think this is the best approach. In reality I only ever use the TV at its maximum resolution which has a defined VIC and this would fix the issue for me.

I just noticed that the user manual for the AV receiver has a list of supported video modes. It only shows VGA (640x480) and the usual TV resolutions (480, 576, 720 & 1080) which all have VICs. I guess that means that all the higher resolution PC modes are technically unsupported.

> I'm starting to think about not sending infoframes at all or 
> adding some kind of quirk for those intermediate devices...

I'm not sure how you would go about detecting the mid-box since it mostly passes through the EDID of the connected display. Perhaps a module option?

> Do you lose some kind of feature when you turn the infoframes off? Maybe
> sound?

No, sounds works fine without the AVI/SPD infoframes. Sounds even works OK in VIC0 when it isn't passing through any video!

Comment 6 Paulo Zanoni 2012-11-20 19:38:15 UTC

Created attachment 86741 [details]
Minimal patch to set the VICs

So here's the patch we've been talking about.

Set a mode, then do "dmesg | grep ===" to see which VIC is set.

My HDMI monitor has a lot of modes that don't have VICs. The preferred mode does not have a VIC :(

Comment 7 Jon Burgess 2012-11-20 22:55:30 UTC

Created attachment 86801 [details]
dmesg output with patch applied

The patch seems to work great. It initially brought up the display in its default 1080p@50 mode:

=== AVI VIC: 31

I then ran testdisplay and saw it produce good output for many of the modes. Looking through the dmesg afterwards showed that it selected VICs for 20 of the 48 modes that tested. This seems about right.

I then manually tested xrandr with the typical 1080p/i, 720p/i etc and all seemed OK. The VGA mode VIC1 worked once I figured out this was the mode listed as 59.9Hz instead of the 60Hz one.

I have attached the dmesg output from the testdisplay run. The beginning is cutoff since it exceeded 256KB.

Comment 8 Paulo Zanoni 2012-11-21 13:54:43 UTC

Thanks for the detailed testing, it is greatly appreciated! I'll work to get this patch merged now.

On a side note, can you please do the following?
- connect the Yamaha AV receiver, run "xrandr --verbose > yamaha.txt"
- disconnect it, then connect the monitor directly and run "xrandr --verbose > monitor.txt"
- compare the HDMI EDIDs written on both files, to see if the AV receiver actually changes anything on the EDID

Thanks,
Paulo

Comment 9 Paulo Zanoni 2012-11-21 17:08:44 UTC

I submitted a slightly different version to the mailing list:
http://lists.freedesktop.org/archives/dri-devel/2012-November/030768.html

Just in case you want to go there and give a Tested-by tag or comment or something else.

Thanks,
Paulo

Comment 10 Jon Burgess 2012-11-21 21:23:02 UTC

Created attachment 86911 [details]
xrandr --verbose with direct attachment of HMDI2 to TV

Comment 11 Jon Burgess 2012-11-21 21:24:15 UTC

Created attachment 86921 [details]
xrandr --verbose with direct attachment of HMDI2 to TV

sorry, description of previous previous attachment didn't match file

Comment 12 Jon Burgess 2012-11-21 21:25:00 UTC

Created attachment 86931 [details]
xrandr --verbose with HDMI2 -> AV -> TV

Comment 13 Jon Burgess 2012-11-21 21:32:18 UTC

Created attachment 86941 [details]
xrandr --verbose with HDMI2 -> AV -> (no TV)

The av-only shows what the AV receiver itself sends as an EDID if there is no display connected to its output. Presumably these are the modes that the AV receiver would most like to see. It includes some identifying things like..

Manufacturer: YMH
Monitor name: RX-V767

Comment 14 Florian Mickler 2012-12-22 09:25:44 UTC

A patch referencing this bug report has been merged in Linux v3.8-rc1:

commit 374a868a726eb8a1cb28ba88805e51ce34222f8d
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Nov 23 12:09:26 2012 -0200

    drm: add drm_mode_cea_vic

Comment 15 Florian Mickler 2012-12-22 09:28:05 UTC

A patch referencing this bug report has been merged in Linux v3.8-rc1:

commit 9a69b885e964cf93064f1a16ddd06ebb7d46ac17
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Nov 23 12:09:27 2012 -0200

    drm/i915: set the VIC of the mode on the AVI InfoFrame