[alsa-devel] Jack event API - decision needed

[Mark Brown]

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?

> that, I can only notice that on my machine, the only processes
> listening to /dev/input files are upowerd (for the lid switch) and
> Xorg (for everything else). [1] Acpid seems to be able to listen to
> these events too, but does not seem to do that on my machine (as
> determined by "sudo fuser -v").

Hrm, right.  So upowerd is an example of a little daemon running as root
which provides an interface to the applications running as users
separately to the X server, and it was added recently too so it should
be an example of current best practice.  However with the lid there is
an additional motivation for doing this as a system daemon as we need to
do power handling even when there is nobody logged in which is less of
an issue for audio especially with the current model we have.

> Xorg can only handle keypresses and mouse events, and AFAICT don't
> care about switch events, so, if the way things are usually handled
> is to add another u-audiojack-d just to forward events to
> pulseaudio, I would prefer giving the user access to the relevant
> input devices directly, out of pure simplicity.

I tend to agree.  I think my preferences would be to open up access to
input (or possibly just switch) devices in general, or if there's a good
reason not to do that then do the daemon thing.