At Thu, 2 Jul 2009 17:27:52 -0500, pl bossart wrote:
Takashi, I looked at your code for jack sensing and I am really confused on how these evolutions will be used. It seems to me these additions with the new control apply only to the HDAudio case. Meaning if Lennart modifies PulseAudio to read the jack sensing information from the new control, Lennart's code will not work on embedded platforms which rely on ASoC and plain snd_jack_report / input layer (or any non-HDAudio based solution for that matter), and we don't have a generic way to providing the jack information to PulseAudio. I had a private discussion with Mark where he stated that ASoC would not change, and would automatically benefit from this additional control. That does not seem to be the case. Either I am missing something (not an unlikely scenario, I am light-years from my comfort zone here) or everyone is on a different wavelength.
The features I want to implement (for HD-audio, so far) are just using the existing framework. That is, you can implement pretty easily on any drivers that can detect the jacks as well. It's just like adding new mixer elements. Once after other drivers need it, we can move the helper functions to the common layer.
In other words, the jack reporting over control API is generic, in the sense as generic as mixer controls. And, it doesn't conflict with the existing jack input layer.
Takashi
Thanks for your feedback, Cheers
- Pierre
On Fri, Jun 19, 2009 at 5:08 AM, Takashi Iwaitiwai@suse.de wrote:
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.
Don't worry, it's kept as is. The control elements are just additions.