On 08/21/2012 08:16 AM, Mark Brown wrote:
On Tue, Aug 21, 2012 at 02:30:51PM +0200, David Henningsson wrote:
On 08/21/2012 02:05 PM, Mark Brown wrote:
- sound/core/ctljack.c which was added later and provides separate
in-kernel and userspace APIs and is currently only used by HDA.
This is wrong. PulseAudio uses the new ctljack API. I started out
with an implementation which used the input device API
(sound/core/jack.c), but since some people did not like this API,
the ctljack API was designed and implemented for PA to use, which it
does (since PulseAudio 2.0 - the input device API implementation in
PulseAudio was never merged upstream).
...and the only thing using this API to generate events is HDA which is
what I was talking about here given that this is a question from a
driver point of view.
What I'd like to see happening is that we merge ctljack into jack (since
only HDA is going to be affected by that change it seems like the right
direction to make the merge) and also add extcon support, I have looked
at the extcon support.
I don't know either why we have two different interfaces for jack
detection (not counting extcon) for driver writers. I think we
should merge jack and ctljack, as long as that does not mean you
break anything I'm relying on in ctljack.
Maybe something for discussion at Plumbers?
We discussed this last time we all met and came to the above conclusion :/
Short term for drivers used on embedded systems I'd have to recommend
extcon rather than anything ALSA-specific.
I thought that when Takashi did the new ctljack interface, that
would effectively deprecate the old input device interface, and that
ctljack was the new recommendation.
Android currently uses the out of tree version of the extcon ABI (like I
say it's where the code originated), and some OSs do use the input ABI
also but realistically if you've got to pick one Android is where the
market is at.
So, it seems that the way to go is extcon. I guess that ALSA will use
extcon just like today snd_jack uses the input driver. is this correct?
Is there any chance that ctrljack will propagate the events through
extcon? Is there any early implementation that I could look at? I am
asking to know how feasible is to use ctljack today and be compatible
with extcon in the future.
Thanks!
Ricardo
To my knowledge no embedded OS is using the control jacks, it's possible
that there's something using them as a function of using PulseAudio but
the ones I'm famililar with currently ignore PulseAudio routing and just
use the mixing facilities. Given the dependency on alsa-lib it'd be an
inconvenient ABI to adopt for most of them.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
