All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Henningsson <david.henningsson@canonical.com>
To: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	Jesse Barnes <jesse.barnes@intel.com>,
	"Zanoni, Paulo R" <paulo.r.zanoni@intel.com>,
	Wang Xingchao <xingchao.wang@linux.intel.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	"Girdwood, Liam R" <liam.r.girdwood@intel.com>,
	"Lin, Mengdong" <mengdong.lin@intel.com>,
	"Li, Jocelyn" <jocelyn.li@intel.com>,
	Takashi Iwai <tiwai@suse.de>
Subject: Haswell: Ensuring HDA codec pins refer to physical outputs
Date: Thu, 16 May 2013 09:00:06 +0200	[thread overview]
Message-ID: <519483F6.9060308@canonical.com> (raw)

Hi,

I want to take this problem up again, because it's important we get this 
right.

The HDA driver assumes that a codec pin widget node always refers to the 
same physical output. With Haswell, it seems like this is not guaranteed 
to be true. I would like to see this fixed on the graphics side. If not, 
I don't know how to work around it on the audio side.

The problems that occur on the audio side are:

  1) Some BIOSes set default pin config. E g, if the machine has a 
single HDMI out, it can set two of the codec pins to "not connected" and 
let the third remain "jack". As a result, the HDA driver will ignore the 
two codec pins and only enable the third. As such, HDMI audio will not 
work correctly, unless it's the third codec pin that is connected to the 
physical output.

  2) Saving and restoring mutes, volumes etc is done on a per-pin basis. 
E g, imagine that a user has a dual monitor setup and always wants audio 
output from the left side monitor, and keep the right side monitor 
silent. If it is not reliable which codec pin refers to which physical 
output, one day suddenly the sound might come out on the right side 
monitor instead.

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

             reply	other threads:[~2013-05-16  7:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-16  7:00 David Henningsson [this message]
2013-05-27  7:30 ` Haswell: Ensuring HDA codec pins refer to physical outputs Wang xingchao
2013-05-27  8:21   ` David Henningsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=519483F6.9060308@canonical.com \
    --to=david.henningsson@canonical.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jesse.barnes@intel.com \
    --cc=jocelyn.li@intel.com \
    --cc=liam.r.girdwood@intel.com \
    --cc=mengdong.lin@intel.com \
    --cc=paulo.r.zanoni@intel.com \
    --cc=tiwai@suse.de \
    --cc=xingchao.wang@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.