Re: Jack event API - decision needed

Takashi Iwai
2011-06-20T17:37:32Z

At Mon, 20 Jun 2011 18:31:01 +0100,
Mark Brown wrote:
>
> On Mon, Jun 20, 2011 at 07:12:21PM +0200, Takashi Iwai wrote:
> > Mark Brown wrote:
> > > On Mon, Jun 20, 2011 at 03:37:25PM +0200, David Henningsson wrote:
>
> > > > I'm still new in the community in that sense that I'm not sure how
> > > > decisions are made. But I could use the outcome of such a decision.
>
> > > So, I'm still not 100% sure what the actual technical issue is here?
>
> > The device permissions. They are set inaccessible from the normal
> > desktop user as default.
>
> Right, I got that much but what I was trying to say in the rest of the
> paragraph was that it wasn't immediately obvious to me that this was due
> to needing to do something special for audio jacks. That's certainly a
> symptom but what's not clear to me is why we think the current setup is
> a good call for the generic input device that udev didn't have specific
> magic for. We seem to have jumped straight into some very non-generic
> solutions, skipping quite a few steps in understanding what the current
> situation is.

True. OTOH, the input-jack devices of the sound driver belong to the
sound device (from device-tree POV), so it's natural to take the
similar control for them as the sound devices. So, I initially
thought it'd be OK in that way.
But, maybe the situation will change when the jack layer is used more
widely for other device classes.

> > > There's a reasonable amount of usage in the embedded space.
>
> > Do they use udev? And don't they need to tweak the device permissions
> > of these input-jack devices on the fly per user?
>
> No and no. The physical user owns the whole device and typically there
> aren't user accounts in that sense on the system.

OK, thanks for clarification.

Takashi