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