On Mon, Feb 13, 2012 at 06:40:23PM +0100, Takashi Iwai wrote:
Mark Brown wrote:
With these patches I'm mainly looking for a quick and simple refactoring to get rid of the duplication - once we've got rid of the duplicate driver APIs then we can refactor the internals of the implementation however we like but there's a pretty pressing need to fix the driver API and get all the drivers doing the same thing to userspace even if it's not ideal.
Hm, then I'd say let's hold on. Merging this half-baked stuff is rather confusing at this point since the use of kctl jack isn't targeted yet for ASoC.
I believe what we need _now_ is to decide the policy (i.e. element naming rule and TLV definitions) for kctl jacks quickly.
Now that the kctl jacks are there I'm getting people asking me about it often enough so I'd like to see it merged.
In other words, if 1:1 mapping isn't needed, we don't have to create a different name string at all. Just create "Jack Detect" controls with different indices and with corresponding TLVs. This would be enough (could be even easier) for a machine parser.
That'd work I think, though I would create a new control for each physical jack at least just for clarity.
They are indeed individual ctl elements. They just share the same name and are distinguished by the index numbers. For the parser program, it would be even easier because it needs to look only for elements containing the single string. The rest is the parse of TLVs of gathered elements, which would be needed no matter whether we have multiple name strings or not.
I think we're mostly agreeing here - what I'd like is to be able to give each jack a descriptive name which shows up in the control name ("Headset", "Docking Station") along with "Jack" or some other keyword. The descriptive name could be optional, but it seems nice to put it in the control name.
And, it seems that there is no standard rule defined for the id string of input-jack. If 1:1 model is used, we'd need to define this rule.
The input stack doesn't have the same concept of machine parsable names for things that ALSA does (honestly that's pretty unique to ALSA within the kernel) - the names it users are all free form text intended to be meaningful to humans only.
Yeah, maybe. But, if you have two headset jacks, how would you identify with the current jack stuff...?
You've just got the descriptive name to go on, there's no way to directly associate it back.
So, at this point, I can list the following policies for kctl jacks:
A. all kctls have one name string with different indices. Each jack is distinguished by the TLV provided to each kctl.
B. kctls are built with only a base name ("Headphone", "Mic") with different indices and TLVs.
C. kctls contain unique names ([location] base [direction] [channel]) optionally with TLVs
I think I prefer B here with the base name being a descriptive name (which could often be like the above) that should be unique within the card, even if the driver just adds numbers.