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. > 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. > 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)? > > Didn't we discuss in the past about the possibility to store the > > profile name in the card component string? > It's already possible to extract any information from the components string. > The current UCM is very flexible, but it does not allow to use a missing > information. > The main questions is: Can we make those strings writable or not? What > prevents us to not allow that? Like I say I'm nervous about potential confusion if we allow people to change things that were already set and used by the kernel, plus the general desire to encourage better quality of implementation from firmware where we can.
Attachment:
signature.asc
Description: PGP signature
