Re: [RFC] Channel mapping API

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1599 bytes --]

On Tue, Aug 21, 2012 at 04:49:56PM +0200, Takashi Iwai wrote:
> Mark Brown wrote:

> > Or perhaps what we want to do here is define the channel mapping in
> > terms of saying "I'm connecting to this input/output" and then use the
> > jack interface to describe all inputs and outputs rather than just jacks
> > (making sure it's easy to see which ones can change state)?

> It's an interesting idea.  But, in the case of HDMI, there are no
> multiple jacks, so this won't fit.

Surely the jack should be able to change state, though?

> What I had in my mind originally is to provide the definition of
> values in TLV, and get/set points the value index.

> However, this doesn't help much for multiple output cases like
> ice1712.  So far, I ignored that case intentionally.  The primary goal
> of this API is to provide a way for apps to decide the channel map for
> multi-channel streams.  If multiple positions are given, what they
> should do?  It'd be just confusing.

This sort of stuff is why I was suggesting providing a mechanism for
saying "fall back to tracing the routing graph" - obviously there's an
implementation to do there but it should provide ultimate support for
whatever mappings people can dreamm up.

> At least, some fixed multiple outputs could be covered by the free
> definition of the chmap value like above (e.g. by allowing multiple
> assignments per channel in the definition block).  But whether to
> cover all flexible multiple outputs per channel, I hesitate to go
> forward...

I agree, I think it'd be too complex to cover every case purely in
channel mapping.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]