[alsa-devel] [PATCH 2/4] ALSA: hda - Return error when open empty hdmi device

[David Henningsson]

On 06/17/2013 01:54 PM, Wang, Xingchao wrote:
>
>> -----Original Message-----
>> From: David Henningsson [mailto:david.henningsson at canonical.com]
>> Sent: Monday, June 17, 2013 4:24 PM
>> To: Wang Xingchao
>> Cc: tiwai at suse.de; daniel.vetter at ffwll.ch; alsa-devel at alsa-project.org;
>> intel-gfx at lists.freedesktop.org; Wang, Xingchao
>> Subject: Re: [PATCH 2/4] ALSA: hda - Return error when open empty hdmi
>> device
>>
>> On 06/14/2013 05:20 PM, Wang Xingchao wrote:
>>> when user open HDMI device 3/7/8, if it has no physical device
>>> connected, return error.
>>
>> This patch will cause regressions in two big use cases:
>>
>>    1) Older chipsets (at least from non-Intel vendors) might not support correct
>> ELD reporting. Thus this will cause HDMI audio to stop working there.
>
> Thanks for pointing this out. It's a good case I missed. :)
> I thought ELD info was monitor specific, and reported on common platforms.

We have a generation of Nvidia cards that does not support presence 
detect (and no ELD) for the audio codec at all.

I'm not sure if we also have cards where presence detect works, but 
there never comes any ELD. Or if this can potentially vary depending on 
the connected monitor. But I think this should also be handled in the 
best way.

> But sometimes user get confused when opening a hdmi device and started to play audio,but
> hear nothing, even there's no error message. Is there any way for old chipset which has no
> correct ELD reporting but do have audio functionality? App should check before really play audio on the device.

PulseAudio (with support from some of the GUIs) support looking at the 
Presence Detect, and "hiding" the device if nothing is currently connected.

I agree in principle with that you should be given some warning if you 
try to play back to unconnected things, but for me it's not a high 
priority to improve.
E g, the situation is the same for analog audio - imagine a small 
desktop with only a headphone output: you can still play audio to the 
headphone output even when there's no headphone connected in the jack.

>>    2) In PulseAudio's current design, PulseAudio probes the device at startup
>> and caches the result. Unfortunately, there is no reprobing at plug/unplug, so if
>> the monitor is hotplugged, it will not work unless PulseAudio is restarted
>> afterwards.
>
> For haswell ult board only,  DDI port D is not supported, this results in screen flicker when playing on third pin.
> But for other haswell boards, the DDI port D is normal. So at first glance my idea is to disable opening device
> without physical device connecting.

Maybe it's possible to fix on the gfx side? It sounds like a graphic 
driver bug if the screen flickers due to anything happening on the audio 
side.

>
> Thanks
> --xingchao
>
>>
>>
>>> The bug is from Haswell platform, All pins choose converter 0 by
>>> default in hardware level, maybe only pin 1 had valid monitor
>>> connected. if user play audio on pin 0/2, pin 1 can get audio data too.
>>>
>>> Signed-off-by: Wang Xingchao <xingchao.wang at linux.intel.com>
>>> ---
>>>    sound/pci/hda/patch_hdmi.c | 3 +++
>>>    1 file changed, 3 insertions(+)
>>>
>>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
>>> index 8db5eb6..d766f40 100644
>>> --- a/sound/pci/hda/patch_hdmi.c
>>> +++ b/sound/pci/hda/patch_hdmi.c
>>> @@ -1139,6 +1139,9 @@ static int hdmi_pcm_open(struct
>> hda_pcm_stream *hinfo,
>>>    	per_pin = get_pin(spec, pin_idx);
>>>    	eld = &per_pin->sink_eld;
>>>
>>> +	if (!eld->monitor_present || !eld->eld_valid)
>>> +		return -EIO;
>>> +
>>>    	if (codec->vendor_id == 0x80862807)
>>>    		hsw_verify_cvt_D0(spec, codec);
>>>
>>>
>>
>>
>>
>> --
>> David Henningsson, Canonical Ltd.
>> https://launchpad.net/~diwic
>



-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic