On Fri, 23 Oct 2015 07:30:12 +0200, Lin, Mengdong wrote:
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Thursday, October 22, 2015 4:53 PM
[snip]
I'll try to explain my suggestion (which I believe Takashi's buying too) one more time then:
First, when a monitor is plugged in, we need to dynamically assign this monitor to five PCM devices. I believe this scheme will be best:
For a monitor at pin nid 0x05, dev index 0, it will prefer PCM 3. For a monitor at pin nid 0x06, dev index 0, it will prefer PCM 7. For a monitor at pin nid 0x07, dev index 0, it will prefer PCM 8. For a monitor at dev index 1 (any pin), it will prefer PCM 9. For a monitor at dev index 2 (any pin), it will prefer PCM 10.
For monitors at dev indices > 2 (can that happen?), or if the PCM is already assigned to something else, try PCMs in this order: 9, 10, 3, 7, 8. (Subject to discussion perhaps, I don't think the order matters too much, because conflicts will be rare in practice.)
Hi David,
Would you please clarify why PA needs such a fixed binding between PCM 3,7, 8 and pin 0x05,6,7?
It's not PA's requirement. The only concern here is for people who uses ALSA device directly, e.g. via aplay -Dhdmi:2. The first monitor is guaranteed to be mapped to the compatible position for such people.
And how will PA handle PCM 9,10 in a different way? They are not bound to pins, and even not able to dev indexes. In practice, a platform will usually support either a DP port or a HDMI port from the Intel integrated GPU for cost consideration. But theoretically i915 can use same device index on two different pins to connect monitors, e.g. pin 0x05, dev index 2 for one monitor and pin 0x06, dev index 2 for the other.
On Intel platforms, the max dev indices is 2. Not sure about Nvidia and AMD.
The whole number should be min(pins * 2 - 1, pins * 64). It's two for Intel, and 7 or more on AMD/Nvidia.
As we've discussed, this "reserved" area is basically optional. We have them for keeping compatibility more easily. Even if this are is exhausted, you can still try to map to any empty slot as the last resort. So, in practice, maybe adding just two extra for this reserved area should suffice. That is, the scheme is:
- Try a static mapping at first - If already occupied, try a dynamic mapping in reserved area - If a dynamic mapping area is exhausted, try to find any empty slot
The device index number doesn't matter. If it conflicts, try another.
Takashi