sound connector detection

sound connector detection

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

Hi,

One Apple machines I have with snd-aoa the situation that the alsa
driver can detect changes in in/output connector state ("is headphone
plugged in" etc.) and currently surfaces it through a read-only alsa
mixer element. That isn't really ideal since nothing is prepared to
handle such events, hence I provide an additional control that allows an
in-kernel toggle from speakers to headphone on headphone plug (and vice
versa).

I'd really like to see this handled in userspace (additionally or
possibly event instead), since there are complications especially with
input (line-in) detection and user preferences of what should happen
then. The number of cases can become large, especially when throwing in
digital and combo connectors that aren't handled yet.

Now, is it appropriate to create an input device for the state of these
things and add new constants like SW_LINEIN_INSERTED,
SW_LINEOUT_INSERTED, SW_OPTICALOUT_INSERTED, SW_OPTICALIN_INSERTED and
if so, how do I reflect the fact that on some machines optical and
analog input/output is mutually exclusive, while on others it isn't?
That would probably require another SW_COMBO_IN/OUT set...

Or should I simply stick with (a) read-only mixer control(s), and for
the mutually exclusive case create a tristate (none, optical, analog)
one? But SW_HEADPHONE_INSERT already exists, so we may want to do this
identically on different machines.

Comments appreciated.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: sound connector detection

[Dmitry Torokhov]

On Friday 30 June 2006 08:49, Johannes Berg wrote:
> Hi,
> 
> One Apple machines I have with snd-aoa the situation that the alsa
> driver can detect changes in in/output connector state ("is headphone
> plugged in" etc.) and currently surfaces it through a read-only alsa
> mixer element. That isn't really ideal since nothing is prepared to
> handle such events, hence I provide an additional control that allows an
> in-kernel toggle from speakers to headphone on headphone plug (and vice
> versa).
> 
> I'd really like to see this handled in userspace (additionally or
> possibly event instead), since there are complications especially with
> input (line-in) detection and user preferences of what should happen
> then. The number of cases can become large, especially when throwing in
> digital and combo connectors that aren't handled yet.
> 
> Now, is it appropriate to create an input device for the state of these
> things and add new constants like SW_LINEIN_INSERTED,
> SW_LINEOUT_INSERTED, SW_OPTICALOUT_INSERTED, SW_OPTICALIN_INSERTED and
> if so, how do I reflect the fact that on some machines optical and
> analog input/output is mutually exclusive, while on others it isn't?
> That would probably require another SW_COMBO_IN/OUT set...
> 
> Or should I simply stick with (a) read-only mixer control(s), and for
> the mutually exclusive case create a tristate (none, optical, analog)
> one? But SW_HEADPHONE_INSERT already exists, so we may want to do this
> identically on different machines.
> 

Hi Johannes,

I am not too happy with putting this kind of switches into input layer,
it should be reserved for "real" buttons, ones that user can explicitely
push or toggle (lid switch is on the edge here but it and sleep button
are used for similar purposes so it makes sense to have it in input layer
too). But "cable X connected" kind of events is too much [for input layer,
there could well be a separate layer for it]. If we go this way we'd have
to move cable detection code from network to input layer as well ;)

-- 
Dmitry

Re: sound connector detection

[Richard Purdie]

Hi,

On Sat, 2006-07-01 at 16:09 -0400, Dmitry Torokhov wrote:
> I am not too happy with putting this kind of switches into input layer,
> it should be reserved for "real" buttons, ones that user can explicitely
> push or toggle 

Playing devil's advocate, by inserting a headphone cable, you push the
switch - the user can explicitly control that switch but inserting or
removing the cable...

> (lid switch is on the edge here but it and sleep button
> are used for similar purposes so it makes sense to have it in input layer
> too). But "cable X connected" kind of events is too much [for input layer,
> there could well be a separate layer for it]. If we go this way we'd have
> to move cable detection code from network to input layer as well ;)

I have mixed feelings about this and can see it from both sides. In a
lot of cases, we need to report these "switch" events to userspace as
only userspace can determine the correct action. Taking some examples,
just from the Zaurus:

Upon lid closure should:
  - the screen/backlight be turned off?
  - the device suspended?

Upon insertion of a headphone jack should:
  - the external speaker be turned on/off?
  - does the jack connect to headphones, a headset, mic or line in
source? (no autodetection so the user has to select and only then can
the mixer be appropriately configured)

Only userspace can make these decisions so we need to pass them there so
it can decide how to handle things. In the case of the Zaurus, we have a
program called zaurusd which listens for the events and knows how to
handle them (http://svn.o-hand.com/view/misc/trunk/zaurusd/). It turns
these events into something the user can influence with scripts.

There is also a question of which USB client to load when  USB client is
detected - again, this insertion event really needs to be passed to
userspace for a decision. I've not touched this issue yet and adding
switch events for client cable detection would probably get frowned
upon?

One thing the input system does well is pass simple switch events to
userspace though its event devices. Not using the input system for
switch like events like these is going to result in code duplication.

I can understand the concern with not wanting to fill the input
subsystem with events that have a tenuous relationship to input devices.
Perhaps the solution is to separate the events layer from the input
layer and start to allow it to handle more generic events?

One of the issues is the ownership of the events data. Currently, you
can't tag a given source of events to a given soundcard. Perhaps each
soundcard would create a separate events device but we need to think
about things like this. Some switch events have no real parent (like the
lid switch on the Zaurus which if anything does belong to the keyboard
driver). Others like the headphone switch on the zaurus arguably belong
to the ASoC sound device (not in mainline yet but coming soon).

In the audio case, there is perhaps an argument for some kind of
scenarios handling where the mixer has some predefined states which get
activated given certain circumstances. The Zaurus ASoC implementations
already sort of implement this having controls which set the headphone
jack mode (headphones, headset, mic, line, off). There is still a need
to ask userspace what was inserted though which requires some kind of
event system.

Even if the audio situation improves, it doesn't solve the general event
case either. Can anyone see a way forward? Would some kind of generic
event code that any device could add to its sysfs directory work? Could
such a thing be abstracted from the input system code?

Richard

Re: sound connector detection

[Dmitry Torokhov]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

On Sunday 02 July 2006 05:28, Richard Purdie wrote:
> One thing the input system does well is pass simple switch events to
> userspace though its event devices. Not using the input system for
> switch like events like these is going to result in code duplication.
> 

I think that hotplug/uevent like mechanism would be better suited here.
You want to monitor changes in system state and you do not really want
to monitor myriad of devices but just latch onto one data feed and get
all the data from it (unlike input devices where you might want to
separate data coming from different devices). The following "event"
might be a good starting point:

	struct system_change_event {
		struct timeval time;	/* look for 32/64 bit issues */
		__u16 type;
		__u16 code;
		__s32 value;
		char object_path[224];
};

Maybe we should start looking into connector or a pure netlink implementation.

-- 
Dmitry

[-- Attachment #2: Type: text/html, Size: 1217 bytes --]

Re: sound connector detection

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 245 bytes --]

On Sun, 2006-07-02 at 22:48 -0400, Dmitry Torokhov wrote:

> Maybe we should start looking into connector or a pure netlink
> implementation.

Might not be a bad idea. Then again, the whole alsa API could work over
netlink ;)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: sound connector detection

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]


> I am not too happy with putting this kind of switches into input layer,
> it should be reserved for "real" buttons, ones that user can explicitely
> push or toggle (lid switch is on the edge here but it and sleep button
> are used for similar purposes so it makes sense to have it in input layer
> too). But "cable X connected" kind of events is too much [for input layer,
> there could well be a separate layer for it]. If we go this way we'd have
> to move cable detection code from network to input layer as well ;)

I sort of see the point. But I think it is indeed unfortunate that we
have all these events scattered throughout. I could live with the
current approach abusing the alsa mixer API, but there's little point in
making that element user-visible. So maybe I just need some new alsa
definitions here.

Although, come to think of it, a daemon keeping the mixer open blocks
unloading the module. I suppose I'd rather have it the other way around
like the eventdev system does -- the device goes away and all reads to
it fail.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [Alsa-devel] sound connector detection

[Takashi Iwai]

At Mon, 03 Jul 2006 15:30:14 +0200,
Johannes Berg wrote:
> 
> 
> > I am not too happy with putting this kind of switches into input layer,
> > it should be reserved for "real" buttons, ones that user can explicitely
> > push or toggle (lid switch is on the edge here but it and sleep button
> > are used for similar purposes so it makes sense to have it in input layer
> > too). But "cable X connected" kind of events is too much [for input layer,
> > there could well be a separate layer for it]. If we go this way we'd have
> > to move cable detection code from network to input layer as well ;)
> 
> I sort of see the point. But I think it is indeed unfortunate that we
> have all these events scattered throughout. I could live with the
> current approach abusing the alsa mixer API, but there's little point in
> making that element user-visible. So maybe I just need some new alsa
> definitions here.

Such a control element doesn't have to be IFACE_MIXER if you want to
hide.  You can use IFACE_CARD, for example, for a card-specific
element but not belonging to the mixer component.

> Although, come to think of it, a daemon keeping the mixer open blocks
> unloading the module. I suppose I'd rather have it the other way around
> like the eventdev system does -- the device goes away and all reads to
> it fail.

That's true.  OTOH, invoking a command at each time isn't always a
good solution, depending on the event-frequency and heaviness.


Takashi

Re: [Alsa-devel] sound connector detection

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

On Tue, 2006-07-04 at 17:55 +0200, Takashi Iwai wrote:

> Such a control element doesn't have to be IFACE_MIXER if you want to
> hide.  You can use IFACE_CARD, for example, for a card-specific
> element but not belonging to the mixer component.

Oh. Good, I'll submit a patch to change that then so that it isn't
there. Someone's probably gonna lart me for it though because it isn't
visible any more ;)

> That's true.  OTOH, invoking a command at each time isn't always a
> good solution, depending on the event-frequency and heaviness.

Yeah, that's the downside of a hotplug type approach.

Well, I'm open for other suggestions. I just dislike the current state
of pushing events through the alsa control elements. Sorta feels wrong.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]