On 06/17/2013 01:54 PM, Wang, Xingchao wrote:
-----Original Message-----
From: David Henningsson [mailto:david.hennings...@canonical.com]
Sent: Monday, June 17, 2013 4:24 PM
To: Wang Xingchao
Cc: ti...@suse.de; daniel.vet...@ffwll.ch; alsa-de...@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:
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.w...@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
