Skip to contentSkip to conversation

udev: Allow ALSA input jacks to be accessed by the current

PATCH In review David Henningsson 4 participants 17 messages Jun 16, 2011 – Jun 17, 2011

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 udev: Allow ALSA input jacks to be accessed by the current

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?

Signature · 2 lines
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

From a45276437c8c3fe62fc001f43d715bfe931dd438 Mon Sep 17 00:00:00 2001
From: David Henningsson <[email protected]>
Date: Wed, 15 Jun 2011 20:36:16 +0200
Subject: [PATCH] udev: Allow ALSA input jacks to be accessed by the current user

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.

---
 extras/input_id/input_id.c              |   23 +++++++++++++++++++++++
 extras/udev-acl/70-acl.rules            |    1 +
 rules/rules.d/60-persistent-input.rules |    1 +
 3 files changed, 25 insertions(+), 0 deletions(-)
extras/input_id/input_id.c +23 -0
index ba53df0..814ce8e 100644
@@ -189,6 +189,25 @@ static void test_key (struct udev *udev,
 		puts("ID_INPUT_KEYBOARD=1");
 }
 
+static void test_sound (struct udev_device *dev,
+		        const unsigned long* bitmask_sw)
+{
+
+	struct udev_device *snd_dev;
+
+	/* Ensure parent is sound card */
+	snd_dev = udev_device_get_parent_with_subsystem_devtype(dev, "sound", NULL);
+	if (!snd_dev)
+		return;
+
+	/* Check that there is at least one relevant switch type */
+	if (test_bit(SW_HEADPHONE_INSERT, bitmask_sw) || 
+	    test_bit(SW_MICROPHONE_INSERT, bitmask_sw) || 
+	    test_bit(SW_LINEOUT_INSERT, bitmask_sw) || 
+	    test_bit(SW_VIDEOOUT_INSERT, bitmask_sw))
+		puts("ID_INPUT_SNDJACK=1");	    
+}
+
 static void help(void)
 {
 	printf("Usage: input_id [options] <device path>\n"
@@ -212,6 +231,7 @@ int main (int argc, char** argv)
 	unsigned long bitmask_abs[NBITS(ABS_MAX)];
 	unsigned long bitmask_key[NBITS(KEY_MAX)];
 	unsigned long bitmask_rel[NBITS(REL_MAX)];
+	unsigned long bitmask_sw[NBITS(SW_MAX)];
 
 	udev = udev_new();
 	if (udev == NULL)
@@ -272,10 +292,13 @@ int main (int argc, char** argv)
 	get_cap_mask (dev, "capabilities/abs", bitmask_abs, sizeof (bitmask_abs));
 	get_cap_mask (dev, "capabilities/rel", bitmask_rel, sizeof (bitmask_rel));
 	get_cap_mask (dev, "capabilities/key", bitmask_key, sizeof (bitmask_key));
+	get_cap_mask (dev, "capabilities/sw", bitmask_sw, sizeof (bitmask_sw));
 
 	test_pointers(bitmask_ev, bitmask_abs, bitmask_key, bitmask_rel);
 
 	test_key(udev, bitmask_ev, bitmask_key);
 
+	test_sound(dev, bitmask_sw);
+
 	return 0;
 }
extras/udev-acl/70-acl.rules +1 -0
index 037349d..a6f54d9 100644
@@ -25,6 +25,7 @@ SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="4|5", TAG+="udev-ac
 
 # sound devices
 SUBSYSTEM=="sound", TAG+="udev-acl"
+SUBSYSTEM=="input", ENV{ID_INPUT_SNDJACK}=="1", TAG+="udev-acl"
 
 # ffado is an userspace driver for firewire sound cards
 SUBSYSTEM=="firewire", ENV{ID_FFADO}=="1", TAG+="udev-acl"
rules/rules.d/60-persistent-input.rules +1 -0
index cd1de4e..d04c09e 100644
@@ -12,6 +12,7 @@ ENV{ID_INPUT_MOUSE}=="?*", ENV{.INPUT_CLASS}="mouse"
 ENV{ID_INPUT_TOUCHPAD}=="?*", ENV{.INPUT_CLASS}="mouse"
 ENV{ID_INPUT_TABLET}=="?*", ENV{.INPUT_CLASS}="mouse"
 ENV{ID_INPUT_JOYSTICK}=="?*", ENV{.INPUT_CLASS}="joystick"
+ENV{ID_INPUT_SNDJACK}=="?*", ENV{.INPUT_CLASS}="sndjack", GROUP="audio"
 DRIVERS=="pcspkr", ENV{.INPUT_CLASS}="spkr"
 ATTRS{name}=="*dvb*|*DVB*|* IR *", ENV{.INPUT_CLASS}="ir"
 
Signature · 1 line
1.7.4.1
#1 lore raw

Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the

Quoted 9 lines · David Henningsson

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?

Thanks,
Kay

#2 lore raw

Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the current user

In reply to David Henningsson

At Thu, 16 Jun 2011 16:28:08 +0200,

Quoted 9 lines · Kay Sievers
Quoted 6 lines · David Henningsson

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.

Quoted 6 lines
Quoted 3 lines

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.

I can't judge more since I haven't seen the patch.

thanks,

Takashi

#3 lore raw

Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the

In reply to David Henningsson
Quoted 15 lines · Takashi Iwai

At Thu, 16 Jun 2011 16:28:08 +0200,

Quoted 13 lines · Kay Sievers
Quoted 9 lines · David Henningsson

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?

Quoted 6 lines
Quoted 2 lines

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.

Na, I mean, I remember you talking about some other channel of notifications about jack changes.

Didn't the input devices get replaced by something on the control device? Or was that just a plan?

Kay

#4 lore raw

Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the current user

In reply to David Henningsson

At Thu, 16 Jun 2011 16:55:39 +0200,

Quoted 20 lines · Kay Sievers
Quoted 18 lines · Takashi Iwai

At Thu, 16 Jun 2011 16:28:08 +0200,

Quoted 15 lines · Kay Sievers
Quoted 9 lines · David Henningsson

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?

Quoted 6 lines
Quoted 3 lines

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.

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.

Quoted 2 lines

Didn't the input devices get replaced by something on the control device? Or was that just a plan?

I had some patches for it years ago, but never got merged. If apps prefer it, I can revisit it. Meanwhile, the jack-input stuff is already present, so it might not be worth for it.

Takashi

#5 lore raw
In reply to David Henningsson
Quoted 15 lines · Takashi Iwai

At Thu, 16 Jun 2011 16:28:08 +0200,

Quoted 13 lines · Kay Sievers
Quoted 9 lines · David Henningsson

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?

Quoted 8 lines
Quoted 2 lines

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.

I can't judge more since I haven't seen the patch.

It was posted to alsa-devel (for comments) two days ago, see:

http://mailman.alsa-project.org/pipermail/alsa-devel/2011-June/040916.html

and

http://mailman.alsa-project.org/pipermail/alsa-devel/2011-June/040917.html

Signature · 2 lines
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
#6 lore raw

Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the current user

In reply to David Henningsson

At Fri, 17 Jun 2011 08:17:07 +0200,

Quoted 26 lines · David Henningsson
Quoted 15 lines · Takashi Iwai

At Thu, 16 Jun 2011 16:28:08 +0200,

Quoted 13 lines · Kay Sievers
Quoted 9 lines · David Henningsson

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?

Quoted 8 lines
Quoted 2 lines

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.

I can't judge more since I haven't seen the patch.

Quoted 7 lines

It was posted to alsa-devel (for comments) two days ago, see:

http://mailman.alsa-project.org/pipermail/alsa-devel/2011-June/040916.html

and

http://mailman.alsa-project.org/pipermail/alsa-devel/2011-June/040917.html

Thanks, I see it now.

Takashi

#7 lore raw
In reply to David Henningsson
Quoted 25 lines · Takashi Iwai

At Thu, 16 Jun 2011 16:55:39 +0200,

Quoted 23 lines · Kay Sievers
Quoted 21 lines · Takashi Iwai

At Thu, 16 Jun 2011 16:28:08 +0200,

Quoted 9 lines · Kay Sievers
Quoted 6 lines · David Henningsson

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.

Quoted 6 lines
Quoted 3 lines

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?

Quoted 7 lines
Quoted 2 lines

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.

Quoted 6 lines
Quoted 2 lines

Didn't the input devices get replaced by something on the control device? Or was that just a plan?

I had some patches for it years ago, but never got merged. If apps prefer it, I can revisit it. Meanwhile, the jack-input stuff is already present, so it might not be worth for it.

As for which architecture works better, I'm not sure. Anyway, my point is, as this is what ALSA currently uses, this is what we should support all the way up the stack. If ALSA switches architecture, let's revisit this patch at that point. (Btw, there are already an experimental set of patches available for PulseAudio that polls for these input events.)

Signature · 2 lines
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
#8 lore raw

Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the

In reply to David Henningsson
Quoted 23 lines · David Henningsson
Quoted 22 lines · Takashi Iwai

At Thu, 16 Jun 2011 16:55:39 +0200,

Quoted 20 lines · Kay Sievers
Quoted 18 lines · Takashi Iwai

At Thu, 16 Jun 2011 16:28:08 +0200,

Quoted 15 lines · Kay Sievers
Quoted 9 lines · David Henningsson

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?

Quoted 15 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines

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?

Quoted 6 lines
Quoted 2 lines

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?

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?

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?

Lennart

Signature · 1 line
Lennart Poettering - Red Hat, Inc.
#9 lore raw

Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the current user

In reply to David Henningsson

At Fri, 17 Jun 2011 14:31:48 +0200,

Quoted 38 lines · Lennart Poettering
Quoted 35 lines · David Henningsson
Quoted 25 lines · Takashi Iwai

At Thu, 16 Jun 2011 16:55:39 +0200,

Quoted 23 lines · Kay Sievers
Quoted 21 lines · Takashi Iwai

At Thu, 16 Jun 2011 16:28:08 +0200,

Quoted 9 lines · Kay Sievers
Quoted 6 lines · David Henningsson

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.

Quoted 6 lines
Quoted 3 lines

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?

Quoted 3 lines
Quoted 2 lines

Na, I mean, I remember you talking about some other channel of notifications about jack changes.

Quoted 6 lines
Quoted 3 lines
Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 3 lines

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

#10 lore raw

Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the

In reply to David Henningsson
Quoted 7 lines · Takashi Iwai
Quoted 3 lines

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.

Well, but I'd guess that the access permissions only really matter for PA, right? So if we say that proper jack sensing via control elements is the way to go, then PA should adopt this new scheme and this new scheme only, and not bother with the input device cruft, and the udev patch should not be merged either as PA would be its only consumer...

Lennart

Signature · 1 line
Lennart Poettering - Red Hat, Inc.
#11 lore raw

Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the current user

In reply to David Henningsson

At Fri, 17 Jun 2011 14:45:52 +0200,

Quoted 7 lines · Lennart Poettering
Quoted 4 lines · Takashi Iwai
Quoted 3 lines

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?

Quoted 6 lines
Quoted 3 lines

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.

Well, but I'd guess that the access permissions only really matter for PA, right?

Not really. For example, I was asked about the input-jack stuff by a couple of vendors for their own products, apparently running without PA.

Quoted 4 lines

So if we say that proper jack sensing via control elements is the way to go, then PA should adopt this new scheme and this new scheme only, and not bother with the input device cruft, and the udev patch should not be merged either as PA would be its only consumer...

I would be against the patch if the change were too intrusive, but this change itself looks small enough to me.
The question whether PA should use it or not is a different thing.

thanks,

Takashi

#12 lore raw

Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the

In reply to David Henningsson
Quoted 14 lines · Takashi Iwai

At Fri, 17 Jun 2011 14:45:52 +0200,

Quoted 11 lines · Lennart Poettering
Quoted 7 lines · Takashi Iwai
Quoted 3 lines

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.

Quoted 6 lines
Quoted 2 lines

Well, but I'd guess that the access permissions only really matter for PA, right?

Not really. For example, I was asked about the input-jack stuff by a couple of vendors for their own products, apparently running without PA.

Well, but the point I am trying to make: the embedded vendors are not interested in the automatic udev ACL management for the jack sensing input devices, right?

That means the udev patch is really and only relevant for usage in PA on desktops.

Quoted 8 lines
Quoted 4 lines

So if we say that proper jack sensing via control elements is the way to go, then PA should adopt this new scheme and this new scheme only, and not bother with the input device cruft, and the udev patch should not be merged either as PA would be its only consumer...

I would be against the patch if the change were too intrusive, but this change itself looks small enough to me.
The question whether PA should use it or not is a different thing.

As I understand Kay he's quite keen on keeping the number of default udev rules small, especially with stuff that people might then start to rely on.

Lennart

Signature · 1 line
Lennart Poettering - Red Hat, Inc.
#13 lore raw

Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the

In reply to David Henningsson
Quoted 13 lines · Takashi Iwai

At Fri, 17 Jun 2011 14:45:52 +0200,

Quoted 11 lines · Lennart Poettering
Quoted 7 lines · Takashi Iwai
Quoted 3 lines

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.

Quoted 6 lines
Quoted 2 lines

Well, but I'd guess that the access permissions only really matter for PA, right?

Not really.  For example, I was asked about the input-jack stuff by a couple of vendors for their own products, apparently running without PA.

I can't imagine they asked for it because they wanted input devces. I guess they just asked for jack-events, didn't they?

Quoted 8 lines
Quoted 4 lines

So if we say that proper jack sensing via control elements is the way to go, then PA should adopt this new scheme and this new scheme only, and not bother with the input device cruft, and the udev patch should not be merged either as PA would be its only consumer...

I would be against the patch if the change were too intrusive, but this change itself looks small enough to me.
The question whether PA should use it or not is a different thing.

The thing is that currently PA doesn't use input jack devices, and honestly I think all the input device misuse must stop. From my point of view jack senses belong entirely to the alsa device domain and not to unrelated fake input devices.

So if you can get the control events working in a reasonable time frame, I would really prefer to add support for that to PA, and nothing is needed on udev's side.

Kay

#14 lore raw

Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the current user

In reply to David Henningsson

At Fri, 17 Jun 2011 15:00:58 +0200,

Quoted 20 lines · Lennart Poettering
Quoted 17 lines · Takashi Iwai

At Fri, 17 Jun 2011 14:45:52 +0200,

Quoted 13 lines · Lennart Poettering
Quoted 7 lines · Takashi Iwai
Quoted 3 lines

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.

Well, but I'd guess that the access permissions only really matter for PA, right?

Quoted 7 lines
Quoted 3 lines

Not really. For example, I was asked about the input-jack stuff by a couple of vendors for their own products, apparently running without PA.

Well, but the point I am trying to make: the embedded vendors are not interested in the automatic udev ACL management for the jack sensing input devices, right?

Ah, no, what I was asked weren't about ASoC but with HD-audio. They were (so-called) multimedia-center devices, so small-factor PCs indeed. I don't know whether udev is used, but I won't be surprised if they do.

Takashi

#15 lore raw

Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the current user

In reply to David Henningsson

At Fri, 17 Jun 2011 15:05:14 +0200,

Quoted 18 lines · Kay Sievers
Quoted 16 lines · Takashi Iwai

At Fri, 17 Jun 2011 14:45:52 +0200,

Quoted 13 lines · Lennart Poettering
Quoted 7 lines · Takashi Iwai
Quoted 3 lines

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.

Well, but I'd guess that the access permissions only really matter for PA, right?

Quoted 6 lines
Quoted 3 lines

Not really.  For example, I was asked about the input-jack stuff by a couple of vendors for their own products, apparently running without PA.

I can't imagine they asked for it because they wanted input devces. I guess they just asked for jack-events, didn't they?

Right. And the only handy and existing solutions were to use these input devices.

Quoted 9 lines
Quoted 8 lines
Quoted 4 lines

So if we say that proper jack sensing via control elements is the way to go, then PA should adopt this new scheme and this new scheme only, and not bother with the input device cruft, and the udev patch should not be merged either as PA would be its only consumer...

I would be against the patch if the change were too intrusive, but this change itself looks small enough to me.
The question whether PA should use it or not is a different thing.

Quoted 8 lines

The thing is that currently PA doesn't use input jack devices, and honestly I think all the input device misuse must stop. From my point of view jack senses belong entirely to the alsa device domain and not to unrelated fake input devices.

So if you can get the control events working in a reasonable time frame, I would really prefer to add support for that to PA, and nothing is needed on udev's side.

OK, it's your call.

thanks,

Takashi

#16 lore raw

Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the

In reply to David Henningsson
Quoted 6 lines · Takashi Iwai
Quoted 3 lines · Kay Sievers

So if you can get the control events working in a reasonable time frame, I would really prefer to add support for that to PA, and nothing is needed on udev's side.

OK, it's your call.

Oh, I think it's actually yours. :)

If you can provide us with the (I think much nicer) ALSA control events, I would wait for that.

But if you tell us that we can expect that anytime soon, we will probably need to merge the PA and udev bits (which I think is sub-optimal).

Thanks,
Kay