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
