At Mon, 20 Jun 2011 17:47:14 +0100, Mark Brown wrote:
On Mon, Jun 20, 2011 at 04:19:51PM +0200, Kay Sievers wrote:
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.
OK, but since jacks aren't at all audio specific (the most obvious additional thing that goes over them is video for cases like composite out on mic and the modern digital standards like HDMI) that wouldn't address the issue. There's also things like docking stations which can present very much like big fancy jacks.
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.
That's not really terribly clever for the non-audio users, they'd have to implement ALSA support.
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.
The input device usage has been present and in use in a basic form since 2.6.18, the ALSA integration of it since 2.6.27 so this isn't terribly new.
It might be nice to have the information available via ALSA but it doesn't seem reasonable to expect anything that might need the information to have to go through ALSA.
Note that the issue came up because David posted a patch for udev to change the device-permission of these input jacks via ACL together with the normal sound devices. Then, the question arose, whether this is needed really for udev for now.
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.
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.
thanks,
Takashi