On 2011-02-01 17:36, Stephen Warren wrote:
David Henningsson wrote at Tuesday, February 01, 2011 1:10 AM:
I've seen a few Nvidia HDMI's recently which have four HDMI codecs connected to the same HDA controller.
This is the case for any NVIDIA GPU that supports HDA, and also our most recent chipset.
The problem is that we don't know which one(s) of these four that is the real one. So people will have to try devices "hdmi:Nvidia,0", "hdmi:Nvidia,1", "hdmi:Nvidia,2" and "hdmi:Nvidia,3" to figure out which one is the right one. (And by empirical testing we know that it isn't always the first one.)
/proc/asound/card<n>/eld* will tell you which one to use; the ELD file numbering should match the hdmi: device numbering.
eld 0,1,2,3 also match hw:$card:$device with device=3,7,8,9.
I do have an audio document that's aimed at technical end-users to explain all of this. However, I haven't quite finished it, and issues with the publication mechanism have stopped me publishing it so far.
Thinking PulseAudio and/or "Just Works", this is not good enough, so is there a way to know beforehand which one of these four that is actually physically connected?
I don't believe it's possible to determine which of the codecs are physically connected to actual connectors on the graphics board. This would be a static facet of the board design.
Ok, thanks for confirming.
As you might have seen, for Intel HDMI I made a patch that makes it act upon the pin config default register. I'd love it if things could work out the same way for Nvidia HDMI. I don't know enough about the BIOS/HW side of things to know for sure, but I guess this will be something up to whoever makes the board (e g Asus) to set inside the GPU somehow.
Failing that, we could try hiding things in the driver by quirking, either at the codec level or at the pin complex level.
Beyond that, the ELD files will indicate which codecs/pins are routed to a connector with an audio-capable display attached and that X is actually sending a signal to. This can dynamically change as the X server is reconfigured, either when X restarts, or dynamically through our management protocol or application.
I'd love BIOS to provide a good codec probe mask, a pin config default, or something similar, but given a codec-proc I can't see any difference between the real ones and the unconnected ones, so I don't know how to fix up the driver without hardcoding/quirking every one of them. Any hints?
ALSA now exposes a logical device (hdmi:Nvidia,n) for each pin complex[1] (equivalently each codec since there's a 1:1 mapping in our GPUs right now). However, PulseAudio still only offers the user the first of these devices, thus causing users to resort to probe masks to select which ALSA device they wish to use.
If PulseAudio were to offer all HDMI devices in its UI, at least the user Could configure their system using the regular GUI tools. I did suggest this on the PulseAudio list, and I think the maintainers agreed this would be a good idea in principle. However, I haven't taken the time to drive this.
http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg07433.htm...
Thanks, reading that thread made a few things clearer.
As for PulseAudio, showing four HDMI devices is quite simple [1] but I still think it would be a little confusing to show four devices to choose from and would wish for something more intuitive.
[1] Concentrating abstractions on pin complexes rather than codecs will ensure ALSA etc. are more ready for other codec/converter/pin combinations that may be seen on other or future GPUs.
I agree.
So let's sum up the options here:
1) Board manufacturer sets a codec probe mask.
2) Board manufacturer sets pin config default register. This might require some support in the driver as well.
1) and 2) won't work for existing boards and I don't know how difficult it would be to persuade the board manufacturers to do it for future boards.
3) Quirking in the driver - codec probe mask
This was my primary option until yesterday, when I saw a machine which had the same PCI SSID for both the primary HDA controller and the Nvidia HDA controller.
4) Quirking in the driver - pin config default register. Will need some work in the driver, but I guess it's doable.
3) and 4) gives us a lot of quirking to do.
5) Show all four devices in PulseAudio. Simple, but confusing for the user.
6) Proper jack detection in PulseAudio, which might be based on ELD information. This is what would need the most work to do, and things will still be confusing for people not using PulseAudio. It might be the long path to go anyway, as it would enable features such as auto-moving to HDMI when HDMI is plugged in, etc.