[alsa-devel] Can a phone hook switch follow alsa jack model?
Hi,
I am wondering if it is a good idea to create support for a phone hook switch, or a handset pick up switch, like that found on Amstrad E3 (Delta) videophone, using alsa jack framework.
After my initial attempt to add support for the switch using gpio-keys driver, I am no longer sure if it is a good idea to follow the keyboard model, that the driver has been designed after, for driving a switch that has nothing to do with keyboards and may required a different approach.
OTOH, the switch is closely related to a handset, and handsets can be seen as sound devices, can't they? So maybe alsa jack would fit better than keyboard?
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.
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.
Thanks, Janusz
-- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 23, 2009 at 03:28:54PM +0200, Janusz Krzysztofik wrote:
After my initial attempt to add support for the switch using gpio-keys driver, I am no longer sure if it is a good idea to follow the keyboard model, that the driver has been designed after, for driving a switch that has nothing to do with keyboards and may required a different approach.
That approach was quite common in the past.
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). You get the input device just the same as you get with gpio-keys so you can do stuff in user space, 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.
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.
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
On Wed, Jun 24, 2009 at 03:28:11PM +0200, Janusz Krzysztofik wrote:
Mark Brown wrote:
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.
Possibly, TBH I had thought I'd seen something for off-hook when I looked at this originally but I can't seem to spot it now.
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.
That's my initial guess - I've not looked at your particular hardware so it may not end up being the best way of dealing with your system but from what you said it was the approach that sprang to mind.
On 2009-06-25 13:05, Mark Brown wrote:
On Wed, Jun 24, 2009 at 03:28:11PM +0200, Janusz Krzysztofik wrote:
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.
Possibly, TBH I had thought I'd seen something for off-hook when I looked at this originally but I can't seem to spot it now.
As I am not native English, please somebody help me to choose best names, both SW_... event name and SND_JACK_... jack type.
During my previous, gpio-keys based attempt, I submitted a patch that added new SW_HANDSET_PICK_UP event definition to include/linux/input.h. Even if not accepted because of no acompanying code that would make use of it, there were no other comments, especially on the name I have choosen. However, there were another name proposed by ams-delta board maintainer, Jonathan McDowell - SW_PHONE_HOOK. Even if my wording may better match those already existing ..._INSERT names, I am not sure which one should I use.
Please also note that SND_JACK_HEADSET, that I temporarily use for now, is an alias for SND_JACK_HEADPHONE | SND_JACK_MICROPHONE. Those two can be seen as matching what a handset actually is. On headset jack insert/remove, two distinct reports/events are generated, one for a microphone, and one for a headphone. Should this schema be used with a handset? Even if it were possible to turn any of handset microphone or headphone individually, would it make any sense?
Sorry for bothering you with all this stuff, but I'd like the changes to existing code I am going to propose, if any, be as much reusable as possible.
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.
That's my initial guess - I've not looked at your particular hardware so it may not end up being the best way of dealing with your system but from what you said it was the approach that sprang to mind.
Mark, Thanks for now, all that seems clear enough for me. Janusz
On Thu, Jun 25, 2009 at 02:48:38PM +0200, Janusz Krzysztofik wrote:
During my previous, gpio-keys based attempt, I submitted a patch that added new SW_HANDSET_PICK_UP event definition to include/linux/input.h. Even if not accepted because of no
Something like hook switch would be a more common name - the switch is closed when the phone is on hook.
comments, especially on the name I have choosen. However, there were another name proposed by ams-delta board maintainer, Jonathan McDowell - SW_PHONE_HOOK. Even if my wording may better match those already existing ..._INSERT names, I am not sure which one should I use.
The _INSERT isn't at all appropriate since there's nothing being inserted here - the _INSERT names refer to the fact that something is being plugged in to a jack.
Please also note that SND_JACK_HEADSET, that I temporarily use for now, is an alias for SND_JACK_HEADPHONE | SND_JACK_MICROPHONE. Those two can be seen as matching what a handset actually is. On headset jack insert/remove, two distinct reports/events are generated, one
OTOH a phone going on hook tends to mean something rather different in UI terms to having something plugged into a jack - it's part of the normal flow of making a phone call.
On Monday 29 June 2009 16:32:15 Mark Brown wrote:
On Thu, Jun 25, 2009 at 02:48:38PM +0200, Janusz Krzysztofik wrote:
During my previous, gpio-keys based attempt, I submitted a patch that added new SW_HANDSET_PICK_UP event definition to include/linux/input.h. Even if not accepted because of no
Something like hook switch would be a more common name - the switch is closed when the phone is on hook.
I guess so.
comments, especially on the name I have choosen. However, there were another name proposed by ams-delta board maintainer, Jonathan McDowell - SW_PHONE_HOOK. Even if my wording may better match those already existing ..._INSERT names, I am not sure which one should I use.
The _INSERT isn't at all appropriate since there's nothing being inserted here - the _INSERT names refer to the fact that something is being plugged in to a jack.
Sure, that's why I tried to replace _INSERT with _PICK_UP, that probably can closely refer to what can happen to a handset, while still following the general trend of ending switch related event names with action names.
Please also note that SND_JACK_HEADSET, that I temporarily use for now, is an alias for SND_JACK_HEADPHONE | SND_JACK_MICROPHONE. Those two can be seen as matching what a handset actually is. On headset jack insert/remove, two distinct reports/events are generated, one
OTOH a phone going on hook tends to mean something rather different in UI terms to having something plugged into a jack - it's part of the normal flow of making a phone call.
That's how I argued once in my message to Jonathan:
I have choosen a different name to distinguish the switch actual function from what we know from telephony world as a switch that connects a phone to a line in response to a handset pick up.
Mark, Thanks for sharing your thoughts. I am not going to waste your time on this linguistic debate any more. For now, I keep on using SND_JACK_HEADSET unless somebody happens to hit upon a better idea. If there are no other votes, I will try to work out a consistent set of symbols using one or another of already considered names that would best match current naming schema.
Cheers, Janusz
participants (2)
-
Janusz Krzysztofik -
Mark Brown