kernel-packages team mailing list archive

["James M. Leddy" <1183125@xxxxxxxxxxxxxxxxxx>]

Hi Jason,

Thanks for your help. Ultimately, I think there is more too it than
that. These are the latest comments from our audio developer, David
Henningsson, about the issue:


I hope I can remember the situation correctly. This is essentially a
longer version of what I wrote before.

First, the unusual thing about these particular devices is that it seems
the integrated monitor is internally connected over HDMI.

This means that, seen from the driver's perspective, there are two HDMI
outputs. This has been less tested than one HDMI output (on Haswell),
but there are chances this works better in the 3.11 kernel - I'm not sure.

Second, the internal monitor does not have any audio capabilities (the
internal analog audio is connected to the ALC668 codec, not the HDMI
monitor), but still, the internal monitor advertises audio capabilities
(as seen in ELD info). This is something we could talk to the OSV about, to
see if they could change this: the monitor should not advertise being
able to play back audio, if it can't.

Third, (maybe meant as a workaround to the just mentioned issue about
ELD info?) some audio codec pins are marked as "not connected" by BIOS.
However, this workaround is not working, at least not on Linux. This is
where I've been trying to get clear answers from Intel, but still have
not received any, even though we have had long discussions and even
phone calls about it.

In short, there seem to be uncertainty on the Intel side how their
hardware actually works: First, how the audio codec pins are actually
connected to the available physical outputs, pipes or transcoders.
Second, if disabling pins in BIOS should be regarded as an error on the
Haswell platform or not. Some Intel developers think so, but we need a
clear statement from Intel that this is the case before we can tell the OEM
they should change BIOS.

I hope this clarifies the status of this issue.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1183125

Title:
  Haswell: Ensuring HDA codec pins refer to physical outputs

Status in intel:
  New
Status in System76:
  In Progress
Status in “linux” package in Ubuntu:
  Incomplete
Status in “linux” source package in Quantal:
  In Progress
Status in “linux” source package in Raring:
  In Progress

Bug description:
  From David's email:

  http://mailman.alsa-project.org/pipermail/alsa-
  devel/2013-May/062105.html

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/intel/+bug/1183125/+subscriptions