At Fri, 17 Jun 2011 14:31:48 +0200, Lennart Poettering wrote: > > On Fri, 17.06.11 13:27, David Henningsson (david.henningsson@xxxxxxxxxxxxx) wrote: > > > On 2011-06-16 17:02, Takashi Iwai wrote: > > >At Thu, 16 Jun 2011 16:55:39 +0200, > > >Kay Sievers wrote: > > >> > > >>On Thu, Jun 16, 2011 at 16:48, Takashi Iwai<tiwai@xxxxxxx> wrote: > > >>>At Thu, 16 Jun 2011 16:28:08 +0200, > > >>>Kay Sievers wrote: > > >>>> > > >>>>On Thu, Jun 16, 2011 at 16:12, David Henningsson > > >>>><david.henningsson@xxxxxxxxxxxxx> wrote: > > >>>>>One missing piece for userspace (PulseAudio etc) to actually be able to use > > >>>>>the jack input devices that ALSA create, is that these devices are > > >>>>>accessible by root only. This patch makes the input device nodes accessible > > >>>>>by the same users that can access the sound card: the current logged in > > >>>>>user, as well as users in the audio group. > > >>>>> > > >>>>>One thing I was thinking about, was that the udev-acl rule actually grants > > >>>>>read-write access to the input device node, where probably only read access > > >>>>>is needed. Is this dangerous? > > >>>> > > >>>>Takashi, wasn't there already something else to use from ALSA than the > > >>>>artificial input devices? > > >>> > > >>>These input devices are just notification from the sound driver at > > >>>jack plugging, so basically it's read-only indeed, and setting the > > >>>file permission RO would make sense. > > > > So the problem is that there is no way to accomplish that in > > 70-acl.rules right now. Would it be some kind of security flaw if we > > allowed write access? What can you really do/damage by writing to > > these things? > > > > >>Na, I mean, I remember you talking about some other channel of > > >>notifications about jack changes. > > > > > >Ah, yeah, it's still possible to implement via ALSA control API, too. > > >Just add a new control element for jack notification, and the apps can > > >listen to it via normal ALSA API like the mixer elements. > > Takashi, what's the perspective on this? Your patches, would they > convert *all* existing drivers to this new interfaces, or just HDA? So far, only HD-audio and ASoC drivers provide the jack-sensing notification. My patch didn't change ASoC drivers, so it's only about HD-audio. > If we add new infrastructure to udev (and PA), does it really make sense > to that with an interface that is suboptimal and is going to be replaced > very quickly anyway? We've had already this infrastructure for years, but mostly used by ASoC, so basically independently from desktops, thus they had little care about the file permissions. > If you have the patches ready to convert all drivers which currently can > do jack sensing over to the new scheme with control elements, then we > should probably focus on that for the future, shouldn't we? For PA work, I suppose so (although I won't object to someone working on the implementation with the present input-jack layer :) But you can see David's patch basically independent from PA. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
