- wait until UCM can describe this hardware and set the DAC
values manually to a sensible value via sequences (the specific hardware levels can be set using the conditions in UCM)
Not an option, there are products that need to ship soon.
It's the easiest method for now. It's just about to change the UCM files without any other changes in the kernel / user space. It's heavily used for SST drivers, isn't?
The current UCM upstream modifies only SOF volume levels (PGA Master
Capture).
that's not right, see above.
I may have misunderstood your point for 3). I assumed you'd need a description coming from the kernel, as we did before for the components (cfg-mics, etc). How would UCM know which of the controls to use without any change to the kernel?
Ideally, yes - it will help to reduce the configuration and the driver already knows more about the hardware. But we can do DMI matching in UCM for now, too.
@Libin Is this modification workable for you? I'd like to know your opinion about it. Thanks.
I think Jaroslav's suggestion of matching DMI is reasonable. Only special platforms should use this feature. Non-dell or some old dell platforms should not use this feature if I understand correctly based on https://www.spinics.net/lists/alsa-devel/msg118123.html In the above link, Mario said the MIC LED is controlled by HW, not the SW.
So the codec driver won't control MIC LED. It means on other platforms which doesn't support the feature of HW controlling LED, using the new kcontrol in UCM will cause some issues. When user press the MIC mute key, the MIC LED won't change the status.
Regards, Libin
Example of the sysfs substitution:
${sys:class/dmi/id/sys_vendor} ${sys:class/dmi/id/product_version}
Jaroslav-- Jaroslav Kysela perex@perex.cz Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
------Please consider the environment before printing this e-mail.