At Sat, 4 Feb 2012 14:02:09 +0000, Mark Brown wrote:
On Sat, Feb 04, 2012 at 01:20:29PM +0000, Mark Brown wrote:
On Fri, Feb 03, 2012 at 06:01:41PM -0800, Dylan Reid wrote:
Is there a plan for the soc code to use the control-based method?
Not exactly. I'm expecting that the new interface will be integrated into the generic ALSA jack support rather than done as a custom thing in the HDA drivers which will mean that anything supporting accessory detect will get support, including ASoC. This stuff should really be handled in the core rather than in individual drivers, there's also extcon which we'll need to integrate with.
BTW, the core code I'm talking about is that in sound/core/jack.c but I just noticed we also acquired a sound/core/ctljack.c.
Takashi, we really need to sort this stuff out - it's all getting very confusing. We've got two different bits of code with very similar interfaces on the driver side but totally different application layer interfaces. From a driver point of view it's not great to have to tell the core the same thing twice and from an application point of view we don't have any consistency.
Yep, absolutely.
Looking at the code I don't understand why ctljack is done separately to the rest of the accessory detection - surely we should just have the snd_jack code create a control for each thing that can be reported? I can't immediately see a problem with just putting a "Headphone Jack" or whatever the naming convention is for these controls on the end of the name that we were given for the base jack (probably support that being empty).
The simple answer is not to break the things right now :)
In the current release, I left ctljack.c as is before the integration with jack.c simply because of different use-cases I faced: the input-jack provides the multiple switches for a single jack while the current ctljack.c provides only a boolean. Although the ctljack can provide an enum instead of a boolean for representing a similar model, I wanted to get the global overlook and a consensus at first.
Meanwhile, the boolean implementation is enough for most of PC (especially HD-audio) stuff and the ctljack implementation was demanded. Thus I decided to merge the branch for 3.2.
Definitely the integration work is necessary and foreseen. The biggest problem my workload for other tasks.
thanks,
Takashi