At Mon, 20 Jun 2011 18:17:45 +0100, Mark Brown wrote:
On Mon, Jun 20, 2011 at 06:59:46PM +0200, Takashi Iwai wrote:
If udev is being used by real users of such input devices, it'd be a good justification. In the previous thread, I also gave some examples that the input-jack device was used for HD-audio media-PC devices, but it's not clear whether udev is used there. And I'm not sure whether there are real users of embedded devices with the input-jack layer that requires udev's ACL handling.
I don't think the embedded space cares desparately about the udev stuff since most of the time the system management daemon which owns this stuff is running as root anyway, PulseAudio or otherwise.
OTOH, if this is mainly targeted for the future extension of PulseAudio, the primary question would become different. Possibly the path via ALSA control API might give more information than the current implementation with the input-jack layer.
I think they can both either give equivalent information or work in concert, I don't see a need to pick between the two.
Yes, we can implement both concurrently. They don't conflict.
Like I say the jacks aren't exclusively for audio use so if we have to rely on the ALSA APIs to get information about them it seems like we're messing up. For things like working out where the jack fits into the audio routing map we'd certainly want to have ALSA API integration but that doesn't mean everything about the jack has to go that way.
Agreed.
Takashi