On Thu, Dec 22, 2011 at 02:55:57PM +0100, Takashi Iwai wrote:
Mark Brown wrote:
A pure addition can still cause problems as we roll out the same interface into other drivers, for example if there's assumptions that aren't generally true.
In later future, yes. But I was talking about 3.3 kernel.
Once we've got a userspace interface we're pretty much stuck with it...
I'm guessing that as this is just a simple boolean each jack will have a series of controls like "Headset Jack Headphone" and "Headset Jack Microphone" or whatever and userspace should match them all together in the same way that it does for Volume and Switch controls?
My current assumption is so, too. OTOH, if a single jack must provide several values inevitably, it may take an integer or an enum, in theory. But I think (and hope) this wouldn't happen.
Supporting multiple objects on a single jack is a very basic requirement in order to support headsets (which exist on PCs as well, the MacBooks for example) - we can usually distinguish between at least headset and headphone. I think if we're going to do this via a single multi-state control rather than a series of booleans it'd need to be an enum for usability ("an object of type 2!"), Android uses integers and it's pretty miserable for usability.
That sounds like it'll work well, we just need to define some strings for standard jacks and conections.
Yeah. Unfortunately this standardization isn't always trivial, especially when multiple jacks are present with the same type...
I was thinking more about the things you might detect rather than the jacks, that's a much more tractable problem.
My idea is to give some association between this jack kctl and another kctl, in a simple way like TLV. But it's likely a new year's dream.
Associating the jacks with the audio routes is definitely a separate problem.