On Tue, Feb 23, 2021 at 08:03:58PM +0100, Hans de Goede wrote: > On 2/23/21 6:20 PM, Mark Brown wrote: > > We already need ACPI and DMI quirks in the CODEC drivers anyway due to > > the limitations of ACPI so it wouldn't be particularly surprising to > > have stuff there. OTOH this would fix things per machine while with > > fancier hardware things might easily be flexible enough that there's > > multiple choices that could be made depending on use case. > I have a feeling from the discussion here that you would prefer this > per model/machine option over the current patch which unconditionally > sets the SNDRV_CTL_ELEM_ACCESS_SPK/MIC_LED flag on the main DAC/ADC > mute controls ? > So I believe that it would be best for me to respin this patch > series moving to making this a per model/machine thing, correct? Yes, we at least need to be able to do that even if we end up hard coding it in some CODEC drivers as the device is inflexible. There are devices where the concept of "main DAC/ADC" just doesn't apply. > > I'd be a lot more comfortable with ASoC having some runtime control for > > overriding which controls get mapped, even if we try to pick defaults > > with quirks. > The drivers in question already allow overriding their quirks bitmap > via a module-parameter. If we are going to enable the mixer-element I'm not a big fan of module parameters TBH, it's not great for usability. > And then the user can always override the settings using the quirk > module parameter. This is not exactly runtime control, but IMHO it > is close enough and anything else will just overcomplicate things. > I'm aware of only 3 model 2-in-1s which need this and on those > 3 the implementation is very straight forward. The problem I was thinking of is the situation where there are multiple options for the mute control in the hardware and it's a configuration decision which one to use.
Attachment:
signature.asc
Description: PGP signature
