[PATCH] ALSA: core - add more card sysfs entries

[Jaroslav Kysela]

Dne 08. 04. 21 v 18:22 Mark Brown napsal(a):
> On Thu, Apr 08, 2021 at 05:01:14PM +0200, Jaroslav Kysela wrote:
> 
>> There are two things to consider (please, don't concentrate to UCM here):
> 
>> 1) the card identification
>> 2) the user experience
> 
>> Actually, the generic ASoC drivers are too much generic and they didn't
>> provide a solid information about the hardware.
> 
> So if the information provided through the driver is too generic then we
> should ideally be fixing those drivers/systems to do something sensible.
> For the DT systems the generic cards have properties that let the system
> just specify names directly so it will just be a case of setting them
> properly and it should just be the x86 systems that are a problem.  ACPI
> is a bit of a lost cause here, most of the systems aren't interested in
> supporting Linux in the first place and the idioms there aren't great,
> but for DT it's reasonably tractable to push back on people if there's
> issues and it's much more scalable to do that than telling individual
> users to do that.

DT works only partially. Also, you need the DT compiler to change something,
it's easier to overwrite things in the booted system. The user experience is
lower with DT.

And as Pierre-louis noted, it may be possible to modify the firmware setup in
udev.

>> As you can see, the information for both drivers is quite inaccurate and users
>> (including me) may want some flexibility to change those strings to something
>> else. It may resolve some UCM problems, but it's just one small piece of the
>> issue.
> 
> It feels like if we're conflating end user configuration and what we're
> reporting to userspace for userspace to key off we're going to end up
> causing confusion and/or tying ourselves in knots when people update
> both places, for example if you're trying to figure out which
> configuration was used but the values used to select the configuration
> that was used have changed.
> 
>> Another issue is when the udev driver loader can change some parameters which
>> modifies the driver behaviour and sound device structure for the given card
>> (as discussed in another thread).
> 
> Not sure I've seen that thread, I've certainly not seen anything on
> github.

I meant the e-mail replies to this thread started by Pierre-louis about OEM
firmwares for the SOF driver. Sorry for the confusion.

>> When we have a common standard layer for the plug-and-play handling (udev), we
>> should concentrate to allow changing / refining of this information there.
>> Those strings are not used for anything else than the user space. So from my
>> view, there's no reason to create another mechanism to handle the overrides.
>> It should be a safe, fast, flexible and _optional_ solution. The udev can
>> alter the sysfs attributes directly without any hassle with the file
>> modifications or looking for another way to pass / store this information
>> somewhere.
> 
> We could add a new sysfs file for user overrides, or alternatively have
> a new non-overridable file which contains whatever the kernel would set
> by default so it's always available in case things start to get
> confused (ie, you can always look at the original value even if it's
> been overwritten later)?

It's an interesting idea. Preserving the original strings may be wanted.

					Jaroslav

-- 
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.