On Wed, Jun 22, 2011 at 13:48, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Wed, Jun 22, 2011 at 12:47:35PM +0200, David Henningsson wrote:
On 2011-06-21 14:39, Mark Brown wrote:
On Tue, Jun 21, 2011 at 02:11:15PM +0200, David Henningsson wrote:
[Using the parent device to work out if a jack is an audio jack.]
If you have a better idea about how to determine if a SW_VIDEOOUT jack is actually an audio jack or not, let me know.
I'd have done this by checking for any audio capabilities - if the jack can detect an audio input or output then it's an audio capable jack.
It does sound like we need some input from the udev and more general userspace stack people about how this stuff is usually handled.
I was hoping for Lennart or Kay to answer here as they are more "udev and general userspace stack people" than I am, but lacking
Yes, me too. Kay, does any of this ring any bells from a udev point of view?
At this point, I wouldn't really expect udev to be directly involved. Udev does not really know anything about audio, video, buttons or input devices.
I'm still pretty sure that there should be no fake input devices involved for any jack related things. Especially not in the simple and common desktop case, where the input devices are created by, and direct child devices of the ALSA card device (like Intel HDA). I'm sure, such things just belong to the ALSA control device directly.
We should get the needed patches Takashi already has, refreshed and merged. For PulseAudio we would just add the support for the control device instead of input device support. Udev would not do anything special here, just manage the access permissions for the control device like it already does since years.
There might be odd use cases or use cases where multiple device classes are involved for the same type of jacks, which can probably not be covered by the ALSA-only control device, and where some video/multimedia event channel makes sense too. I don't necessarily see a conflict with the ALSA control device event here, not even with events for the jacks coming out of ALSA control and the multimedia device at the same time.
To me the ALSA control device events for audio-related jack events seems like the natural interface and the best option currently. Unless there are good technical reasons not to do that, I like to see them made working, instead of adding support for input devices, or wait for some (magic) meta multimedia device to be defined, or an additional userspace event daemon requirement.
Thanks, Kay