Hi Jaroslav > -----Original Message----- > From: Jaroslav Kysela <perex@xxxxxxxx> > Sent: 2021年2月8日 19:42 > To: Hans de Goede; ALSA development > Cc: Takashi Iwai; Yuan, Perry > Subject: Re: [PATCH] [RFC] ALSA: control - add generic LED API to sound core > routines > > > [EXTERNAL EMAIL] > > Dne 07. 02. 21 v 21:52 Hans de Goede napsal(a): > > Hi Jaroslav, > > > > On 2/7/21 9:11 PM, Jaroslav Kysela wrote: > >> [DO NOT MERGE!] > >> [This is just an early proposal for comments] [The code is not tested > >> / debugged] > >> > >> The recent laptops have usually two LEDs assigned to reflect the > >> speaker and microphone mute state. This implementation adds a tiny > >> layer on top of the control API which calculates the state for those > >> LEDs using the driver callbacks. > >> > >> Two new access flags are introduced to describe the controls which > >> affects the audio path settings (an easy path for drivers). > >> > >> The LED resource can be shared with multiple sound cards with this > >> code. The user space controls may be added to the state chain, too. > >> > >> This code should replace the LED code in the HDA driver and add a > >> possibility to easy extend the other drivers (ASoC codecs etc.). > >> > >> Note: The snd_ctl_notify_one() changes should be moved to a separate > >> patch. I will do this, when this proposal is agreed. > >> > >> Signed-off-by: Jaroslav Kysela <perex@xxxxxxxx> > >> Cc: Perry Yuan <Perry.Yuan@xxxxxxxx> > >> Cc: Hans de Goede <hdegoede@xxxxxxxxxx> > > > > Nice I think that having this handled in a generic manner would be a > > great improvement. > > > > I have 2 HP x2 models which are Bay Trail resp. Cherry Trail based, > > which means they use Intel's LPE (Low Power Engine) for audio which > > uses ASoC. > > > > These come with detachable USB keyboard-docks which have a speaker > > mute LED. I have already added LED-class support to the HID driver for > > these, but I never got around to hooking up a trigger from the ASoC > > code. > > > > So if I understand things correctly, then if I add this patch to a > > kernel and in the ASoC codec driver add > SNDRV_CTL_ELEM_ACCESS_SPK_LED > > to one or more of the controls, and add .default_trigger = > > "audio-mute" to the led_class_dev for the LED, then if I toggle the > > control on / off in alsamixer this should then control the LED ? > > Yes, the ALSA control code should do just the LED trigger. > The LED class driver is a separate thing. > > > If I got that right I will certainly give this a try. > > > > Any advice for which control would be the best to use? > > Looking at the code, it assumes that if a control is enabled that then > > there will be a route, which makes sense if there are e.g. headphones > > and speaker and lineout controls. But what about chained controls, > > e.g. separate volume + mute controls or multiple volume controls > > chained. With ASoC this is not unheard of. I guess the answer is to > > pick the control which we will also want to use for hw volume-control > > if/when UCM profiles grow hw volume-control support ? > > The proposed implementation just goes through all marked controls and if > any of the marked controls is set to value greater than the minimal value, then > the path is evaluated as "on" (thus the mute LED should be set to off). > > The controls tied to the PCM stream (DAC / DMA) should be marked. The > physical inputs behind a multiplexer without a "global" volume / switch > controls will require a bit different handling. I would just start with something > simple and we can add the more complex things on demand. > > > > > Regards, > > > > Hans > > > > > > > > > > p.s. This would only / at least add proper support for these LEDs at > > the kernel level. ATM these devices which use UCM profiles don't > > actually use any kind of hw volume-control. So we would also need to > > fix that (in userspace) to get these LEDs to really work when an user > > hits the mute key, or lowers the volume to NIL. > > There's already the hw volume support in UCM and in PA (I added this to PA > 14.0). Some drivers like SOF HDA / SoundWire already set the > PlaybackMixerElem / CaptureMixerElem values. It's true that the hw volume > controls are missing for the Intel SST hardware. > > The similar situation is for the SoundWire codecs (missing LED controls, > missing hw volume configuration in UCM). > > Jaroslav > > -- > Jaroslav Kysela <perex@xxxxxxxx> > Linux Sound Maintainer; ALSA Project; Red Hat, Inc. Will this new audio led control implementation be supporting SOF/Soundwire subsystem ? If so, I can help to do some testing rebase my privacy driver which needs the audio led control. Perry
