Re: Jack event API - decision needed

Mark Brown
2011-06-27T12:07:47Z

On Mon, Jun 20, 2011 at 03:37:25PM +0200, David Henningsson wrote:

> 1) We're continuing the path with /dev/input devices

> 2a) We'll rewrite these devices to be read-only ALSA mixer controls

> 2b) We'll rewrite these devices to be something within ALSA, but not
> exactly mixer controls.

> For options 2a) and 2b) I guess the existing /dev/input thing should be
> deprecated and/or removed. So part of decision should maybe be based on
> information about how widespread the usage of these devices are
> currently...?

So, this discussion seems to have ground to a halt. Summarising briefly
it seems that Lennart and Kay both seem adamant that they don't want a
unified jack object visible to userspace, they want to glue the objects
together via some implicit means. Lennart mentioned that there is some
support for at least some of this functionality in PulseAudio already
but didn't provide any details yet - does anyone else know what happens
here or have time to go look at the code?

In kernel I'm concerned that we'll still need to have a unified object
due to the need to share the detection between multiple subsystems, if
one driver can report for multiple subsystems. This seems likely to
mean that we'll end up with some sort of in kernel object for many if
not all jacks.

I'm also concerned that an implicit system may be hard to use from
userspace, if only in terms of figuring out what the rules are for
matching things up.