Re: Jack event API - decision needed

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Wed, Jun 22, 2011 at 02:50:59PM +0200, Kay Sievers wrote:

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

It would really helpful if you could engage with some of the discussion
about this...  Apart from anything else "fake" seems a bit misleading,
a jack is a physical thing which really exists and which I can point to
on the system and in may cases has buttons on it.

> 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

Like I said in reply to your earlier mail on this subject that's not a
terribly unusual case for PC class hardware, HDMI is very widely
deployed and obviously carries both audio and video over a single
physical connector.

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

To summarise some of the issues from the rest of the thread:

 - This isn't a new interface at all, it's been implemented in the
   kernel for quite some time now (the first switch was added in
   2.6.18).  All that's changed here is that PulseAudio is trying to
   use the information that the kernel is exporting.
 - Mixed function jacks aren't that unusual; if anything they're more
   common on PCs than anything else.  HDMI is the obvious one for PC
   class hardware and where these things happen we do need to be able to
   join the audio and the video up with each other.
 - Many jacks include buttons so need an input device anyway which again
   we want to join up with the other functions.
 - We still need to handle cases where the jack isn't particularly
   closely connected to the audio subsystem.
 - There are other non-audio non-jack things being exposed via the same
   interface which we need to have some method for handling even if we
   end up doing something audio specific for some subset of jacks.

and probably some others I forget.