On Mon, Mar 01, 2021 at 08:49:34PM +0100, Hans de Goede wrote:
On 3/1/21 8:15 PM, Mark Brown wrote:
Off the top of my head something like writing a control name into a sysfs file might work, it doesn't scale if you need to use multiple controls as rt5640 does though.
Currently ALSA/UCM does not use sysfs files for anything, so this feels very inconsistent with how all the rest of this currently works.
Yes, you'd really want to add string controls in ALSA.
drivers make a list of all output stage mutes and then use that to build a standard global mute control which functions similarly to this one and could be force wired to the LED trigger input, seems like a big hammer but it'd be reasonably consistent.
/* Speaker Output Volume */ SOC_DOUBLE("Speaker Channel Switch", RT5640_SPK_VOL, RT5640_VOL_L_SFT, RT5640_VOL_R_SFT, 1, 1), SOC_DOUBLE_TLV("Speaker Playback Volume", RT5640_SPK_VOL, RT5640_L_VOL_SFT, RT5640_R_VOL_SFT, 39, 1, out_vol_tlv),
Where userspace expect "Speaker Channel Switch" to be named "Speaker Playback Switch" (aligning it with the vol-control name) instead.
This isn't great but be aware that the control names stuff breaks down very, very easily in the presence of general hardware - things like multiple general purpose outputs can cause problems.
In any case a big hammer virtual control which mapped straight onto the LED would sidestep some of that, though it does assume there are useful mute controls in all the paths which may or may not be the case.
And we cannot just rename this since the control names are used in UCM profiles and if a UCM profile refers to a non-existing control it won't work.
I thought UCM already had support for remapping control names? It was certainly something discussed very early on - a mechanism to allow the UCM file to say "treat control X as name Y in this use case", where the X used for Y might vary between use cases.
I do know that we need to much more careful going forward to make sure that control names match the conventions expected by userspace.
That in general won't scale well, ideally we'd be exposing the routing graph to userspace and annotating the non-DAPM controls onto that routing graph so that userspace can figure out where everything sits - that'd make several things a lot easier. It does require somoene with the time and enthusiasm to define a new ABI though which isn't something you should hold your breath for.