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.
Attachment:
signature.asc
Description: PGP signature
