[alsa-devel] Jack event API - decision needed

[Stephen Warren]

Lennart Poettering wrote at Wednesday, June 22, 2011 3:02 PM:
> On Wed, 22.06.11 14:25, Mark Brown (broonie at opensource.wolfsonmicro.com) wrote:
> > 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.
> 
> I fully agree with Kay here btw.
> 
> Input devices should really just be used for input, i.e. interfacing
> with humans via keyboards, mice, joystick, touchscreens and
> suchlike. However Jack sensing does not qualify as such. The main reason
> why input device exist to do jack sensing right now appears to be that
> there was no other infrastructure readily available for it. But that is
> a poor excuse, which might be acceptable early in the game where things
> aren't really clear yet but not for the long run. On top of that there
> actually always has been a more appropriate place for signalling audio
> jack sensing events: the alsa control layer. Because that is what Jack
> sensing ultimately is: audio control. And if you have it in audio
> control this has many benefits: for example it's in the same namespace
> as the other audio controls (a very weakly defined namespace, but still
> the same namespace), so you could by employing some rules match up mute
> and volume controls with their matching jacks.
> 
> On top of that Takashi has patches ready to port HDA over to jack
> sensing via control devices, and hence I believe this is definitely the
> way to go.
> 
> Jack sensing for video plugs should similarly be handled by the video
> layer -- and actually is handled like that for VGA hotplug already.
> 
> HDMI is a composite technology, but I don't think this should be used as
> excuse to implement jack sensing via an independent subsystem. If it is
> composite it should simply use the native sensing interfaces for its
> technologies, i.e. send plug notifications via both video and audio
> control, the way they want.

For composite devices such as HDMI, with audio and video "sub ports",
user space needs to know which audio port and which video port are the
same physical port. For example, when displaying UI to select an audio
output device, this information is needed to display an X display ID,
monitor name, etc. as an option, which is much more informative to a
user than some random GPU's ALSA PCM device name/number.

It seems like this correlation would be easier to represent with a
single unified jack model, with "sub ports" on each jack for audio,
video, etc.

However, if the jack information is pushed into separate APIs, can they
please at least have some unified naming for the physical ports, so that
user-space can determine which audio jacks are the same as which video
jacks etc.

Thanks!

-- 
nvpublic