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.