Re: Jack event API - decision needed

Kay Sievers
2011-06-20T14:20:07Z

On Mon, Jun 20, 2011 at 15:56, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> Sorry about the top posting, but as I wasn't involved in any of the discussions and am on a mobile device right now and your mail isn't directly legible it would be enormously helpful if you could summarize the issues you're trying to address, your proposed solution and the problems Kay had.

Domain-specific events should not be 'faked' as 'input' devices. No
non-input subsystem should do that if it can be avoided. That 'input'
supports nice and easy events to userspace should not be a reason to
misuse it for pretty much unrelated things.

There are patches to have the ALSA control device emit these ALSA
related events natively. That's would be just better, simpler and more
correct than any additionally created input device.

If Takashi can make that possible in a reasonable time frame, we
should not even start handling the (currently not handled) input
devices in upstream projects like udev and PulseAudio, and focus right
away on the native ALSA control events.

If we can't have the native ALSA events anytime soon for some reason,
we might need to merge the input device support, but I would like to
avoid that.

Kay