Re: [PATCH] [RFC] ALSA: control - add generic LED API to sound core routines

From: Takashi Iwai <tiwai@suse.de>
To: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: Hans de Goede <hdegoede@redhat.com>,
	ALSA development <alsa-devel@alsa-project.org>,
	Perry Yuan <Perry.Yuan@dell.com>
Subject: Re: [PATCH] [RFC] ALSA: control - add generic LED API to sound core routines
Date: Wed, 10 Feb 2021 12:26:24 +0100	[thread overview]
Message-ID: <s5htuqki2ov.wl-tiwai@suse.de> (raw)
In-Reply-To: <20210208223443.GA258185@workstation>

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