Dne 23. 04. 20 v 20:40 Mark Brown napsal(a):
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 just wanted to point to the source location, where the check should be added. If you remove the return, then only the warning will be printed.
Also, we can add the .driver_name to all Intel drivers without the driver name change for the stable drivers. I would prefer the massive change (cleanup also those driver names conditionally), but I know, you're a bit paranoid here ;-)
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.
My point is that this information is duplicated in the sense, that we have three fields with the similar contents passed from the audio driver by the ASoC drivers whose set only snd_soc_card->name from the device tree.
For generic drivers: They can pass a generic driver name (like 'ASoC Simple') for the simple card driver (soc/generic/simple-card.c).
So my proposal is to change the driver_name to the right contents (it was the initial intention for this field - changed somehow for ASoC). An information about the used driver which is independent on the real configuration (device tree, ACPI, component enumeration etc.). In other words, the name should be more close to the source (top-level driver) code name than the hardware configuration.
The hardware configuration may be described in the card names and components string field (struct snd_ctl_card_info), so that the user space can do a more finer usage decision later.
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@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.
The question is if we resist to use this information in this form. UCM2 can read DMI over sysfs (e.g. /sys/class/dmi/id/product_name can be read using ${sys:class/dmi/id/product_name} substitution and do the string / regex matching on it).
I would prefer to have the sound hardware description in the long name field than the whole hardware platform info here, too.
Jaroslav