On Fri, Jun 19, 2009 at 10:04:47AM +0200, Takashi Iwai wrote:
yet another thing I've worked recently on is a bit more generalized framework for jack-sense reporting for HD-audio. This supersedes the existing jack-sense reporting via the input layer. In addition, it gives the corresponding control elements.
It'd be nice to keep the input API interface as well - one of the reasons I carried on with the existing input interface was that the existing userspace stuff I found was using the input API in one way or another. In the embedded space it appears to have often been convenient for people to read jack sense from a GPIO as part of a GPIO keyboard they're already using which was part of the reason it was never really joined up with ALSA in the past.
I suspect that which interface is more convenient will depend on what the application responding to the events is doing. For system-wide things that aren't focused on audio being able to use the general input API makes some sense, while for audio-focused applications that are already using ALSA sitting within the ALSA APIs is useful. This sort of system wide thing is probably more common in the embedded space, though HAL/DeviceKit do similar things in the desktop space for other kinds of hardware.
Perhaps rather than superceeding the existing ABI it'd make sense to have something in user space as either a plugin or part of the library which remaps things into a more ALSA framework? I confess I've no idea what sort of work is involved in doing that; it may be simpler to just provide two ABIs.
For example, you'll have "Jack HP-Out" (or a bit more verbose like "Jack HP-Out at Ext Rear") control via control API as well as other mixer controls. This can notify when a jack is plugged/unplugged.
Including the colours (where reported) is often very helpful for figuring out what's what. The pictures manufacturers seem fond of using for describing the jack functions aren't always models of clarity to the general user.