[alsa-devel] Can a phone hook switch follow alsa jack model?

[Janusz Krzysztofik]

Hi Mark,

Mark Brown wrote:
> On Tue, Jun 23, 2009 at 03:28:54PM +0200, Janusz Krzysztofik wrote:
>> However, I am not sure if the switch in question matches the alsa jack 
>> model closely enough. I see the switch usage not as simple as turning 
>> handset microphone/speaker on or off. It can be used for other purposes 
>> as well, like accepting a phone call or actually dialing a number that 
>> has been just typed in. Furthermore, it can be used to turn off a 
>> speakerphone function, while, in turn, the related handset 
>> microphone/speaker pair can be turned off not only with this switch, but 
>> with a handsfree button as well, for example.
> 
> That can all be accomodated within the ASoC jack framework (I'm assuming
> you'll be doing an ASoC rather than generic ALSA driver).

Right, thanks for pointing out the difference.

>  You get the
> input device just the same as you get with gpio-keys so you can do stuff
> in user space,

Yes, that was quite simple :). For now, I used SND_JACK_HEADSET report 
type. Don't you think that a new type like SND_JACK_PHONE_HOOK or 
SND_JACK_PHONE_HANDSET should be defined for the purpose? Even if 
HEADSET may not be very different from HANDSET, corresponding 
SW_HEADPHONE_INSERT and SW_MICROPHONE_INSERT event names seem have very 
little to do with picking up a phone.

> the main difference is that you can also arrange for some
> of the power management within ASoC to be hooked up with the jack
> automatically as well.
> 
> With what you're describing above I'd tie the mic and speaker in the
> headset to DAPM automatically.

OK, I'll try to follow your advice when I'm ready with a method of 
switching my microphones/speakers.

>> All that extra functionality looks like belonging to userspace rather 
>> then kernel, not like other alsa jack implementations that seem to do 
>> all the job of switching media paths inside the kernel. That is why I am 
>> not sure if the jack model is suitable for the purpose.
> 
> The switching in kernel for ASoC should generally be confined to marking
> outputs as powered or unpowered - things like marking a headphone jack
> as disabled when there's nothing plugged in to it that can be done
> unconditionally.  Everything else should get punted to user space.

So, if I want to follow the ASoC jack model, my in-kernel hook switch 
handler should only power on/off the handset, not touching the 
speakerphone at all. The latter should be controlled from userspace. 
Please correct me if I am missing something.

Thanks,
Janusz