Dne 23. 02. 21 v 15:21 Takashi Iwai napsal(a): > On Tue, 23 Feb 2021 15:09:30 +0100, > Mark Brown wrote: >> >> On Tue, Feb 23, 2021 at 02:59:17PM +0100, Hans de Goede wrote: >>> On 2/23/21 2:45 PM, Mark Brown wrote: >>>> On Mon, Feb 15, 2021 at 03:24:19PM +0100, Hans de Goede wrote: >> >>>> Why just these particular controls - what if a system has separate mutes >>>> for speakers or something? >> >>> These are the main volume controls, which are always in the output / input >>> path independent on if we are outputting to e.g. speakers or the headphones. >> >>> We want to use the main volume control for this, because there always is >>> only 1 output mute LED and 1 input mute LED. Well at least that is the assumption >>> the current ledtrig-audio.c code has. >> >>> The idea is to only turn the single LED on if we are sure there will be not >>> sound output on any of the outputs, which is why we tie the LED to the >>> mute switch on the main volume control. >> >> Right, so that might work well on your particular system with your >> particular configuration but will it work well on other systems with >> different hardware? It's not clear to me that it makes sense to go >> through all the drivers picking controls that might be used for this >> purpose - it seems both time consuming and error prone. Consider a >> mostly digital device which has an ADC/DAC per input/output rather than >> a central ADC/DAC with analogue muxing for example, or a system with >> multiple DACs available for mixing together or analogue bypassess. > > That's one of my concerns in the recent actions for putting the > hard-coded mute LED controls. So far, the only usage of led-audio > trigger is HD-audio, and it's enabled only for selected devices and > setups. OTOH, if we apply the audio-led trigger generically in ASoC > codec driver, it's always done and might misfit; e.g. what happens if > two codecs are present on the system?. That's the abstraction issue. We can use PCI, ACPI, DMI or DT checks at the _right_ place (machine top-level code) to mark those controls with the LED flags in the kernel space. I've never said that the right place is the generic ASoC codec driver. On the other hand, rt5670 is really multi-purpose codec like HDA codecs with the recommended usage/routing from the designer, so it might make sense to add the default LED marking as we do for HDA. > Of course, this implementation would make the integration much easier, > and that's a big benefit. So I have a mixed feeling and not decided > yet whether we should go for it right now... I think that we can reconsider the LED handling implementation later, when someone brings something better on the table. Jaroslav -- Jaroslav Kysela <perex@xxxxxxxx> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
