On 06/17/2013 01:54 PM, Wang, Xingchao wrote:
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Monday, June 17, 2013 4:24 PM To: Wang Xingchao Cc: tiwai@suse.de; daniel.vetter@ffwll.ch; alsa-devel@alsa-project.org; intel-gfx@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:
- 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.
- 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@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