sound connector detection

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

Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________
Alsa-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

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

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Hi,

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...

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

Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

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

Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________
Alsa-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

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

johannes

Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________
Alsa-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

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

Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________
Alsa-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

At Mon, 03 Jul 2006 15:30:14 +0200,

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.

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

Takashi

Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

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 ;)

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

Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________
Alsa-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/alsa-devel