[alsa-devel] Jack event API - decision needed

[Kay Sievers]

On Wed, Jun 22, 2011 at 13:48, Mark Brown
<broonie at 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