ASoC driver names

[Mark Brown]

On Thu, Apr 23, 2020 at 11:17:30AM -0500, Pierre-Louis Bossart wrote:

> I am all for Jaroslav's proposal of making the driver name the basis for UCM
> identification. we've been working on this since e.g. the addition of the
> sof- prefix creates a driver name that makes no sense after a truncation of
> the card name to 16 characters [1] [2] - still WIP.

> Making the card name more user-friendly is also a good thing, there's also a
> nice hidden feature when the card name contains spaces, the last word -
> typically the codec - is used for the card ID.

> But reporting an error when the driver name is not set is a bit extreme and
> would break all Intel boards. I think we want to encourage people to move to
> the suggested solution, but do we want to break existing setups?

That's an issue, yes - it makes me think we need a really strong case to
change things.

> I must admit I also don't see a generic solution when the card is generated
> from a DT description, it's not straightforward to translate parsed elements
> into human-readable ones.

We do let people just fill in an arbatrary string in the generic cards,
not actually checked how many do something sensible though.  This is a
big worry for me, if we're solving the problem by doing something that
doesn't work for generic cards that means that as the generic cards get
better and we need fewer custom cards whatever issues the current
situation causes in userspace will get worse.  For them the commonality
is likely to come from one or more of the components in the card and the
card itself isn't really interesting.

My instinct is that the machine driver name is being used as a
proxy for something else here and that if we need to change the ABI
perhaps we need to extend it rather than trying to shoehorn things into
what's there.

> While I am at it, I think we should probably avoid using the DMI information
> for the long card name. It's just awful. It might be a better idea to add it
> in the component strings (if it fits) so that UCM can use it internally, but
> it's really horrible. Even with the clean-ups suggested by Jaroslav I
> ended-up with this horror of a long name on my test device:

> root at Zotac:~# cat /proc/asound/cards
>  0 [rt5640         ]: SOF - sof-bytcht rt5640
>                       ZOTAC-XXXXXX-XX-CherryTrailFFD

I don't actually appear to have any DMI equipped systems with non-HDA
sound cards but looking at the systems I have (a mix of Lenovo and Dell)
they all have sensible display names in the DMI corresponding to the
model name.  But yeah, outside of enterprise users nobody really pays
attention to DMI so there's serious QoI issues in general.

> If we really wanted to be user-friendly we'd use something like

> "SOF card for Baytrail/Cherrytrail devices with Realtek RT5640 codec"

> and apply the same pattern for all machine drivers.

It kind of depends on how well filled in the DMI stuff is - if it's
badly filled in it's obviously not useful but if you have a clear model
name it works fairly well and matches what a lot of Windows systems do.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20200423/63b1aa5a/attachment-0001.sig>