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
--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
