On Mon, 08 Feb 2021 23:34:43 +0100, Takashi Sakamoto wrote:
Hi,
On Mon, Feb 08, 2021 at 05:33:02PM +0100, Takashi Iwai wrote:
Also, are those new access flags exposed to user-space intentionally, so that user-space gets some information?
Yes, it's one benefit, the second benefit is that we can create user space controls for hardware which does not have any switch / volume controls for the given path.
An example is the AMD ACP bridge with the simple digital microphones. We can use alsa-lib's softvol plugin to control the volume for this and it would be nice to mark this user space control with the mic mute LED flag.
OK, makes sense.
I have a concern about the usage of access flag for such kind of hardware specific stuffs (LED dedicated to specific audio control) since it's not enough hardware abstraction.
In my opinion, for the case, developers for in-kernel driver tend to use specific name for control elements (or prefix/suffix of the name). Adding new access flags for it seems to be overengineering against the original purpose.
The patch itself includes some remarkable ideas that:
- introduction of association between control elements
- analyzing current status of the association (then operate LEDs)
- communication to userspace stuffs about the association
(here I carefully avoid usage of word 'topology'.)
The association itself seems to be useful when cooperating use case manager of alsa-lib. I guess that the kind of framework designed for the association is preferable instead of the patch tight-coupled to LED stuffs. (And some subsystem already attempts to implement such framework into kernel land, e.g. media controller devices in media subsystem.)
In another side, I guess that the reason to supply the association to kernel land is to use 'ledtrig_audio_set()' kernel API. If userspace stuffs find target LEDs and operate them via userspace interface, the association could be in userspace. I think it better to investigate for the direction since I can imagine that the introduction of association to kernel land brings much codes into kernel land to support wide-variety of hardware (and going to be obsoleted according to lifetime of actual hardware sooner or later).
Sakamoto-san's comments made me reconsidering of the situation again. The user-space access like via sysfs was my original idea when the mic mute LED issue came up for AMD ACP driver in the past. One problem is the permission. The r/w control over sysfs is for root, and we want for a normal user. This might be solvable via loginctl or such and adding the dynamic permission via ACL. I didn't investigate enough yet.
Takashi