+config SND_SOC_INTEL_USE_CTL_COMPONENTS
+ bool "Use CTL components for I/O configuration"
+ help
+ Some drivers might pass the I/O configuration through the
+ soundcard's driver name in the control user space API.
+ The new scheme is to put this information to the components
+ field in the ALSA's card info structure. Say Y, if you
+ have ALSA user space version 1.2.2+.
+
If this is at the board level, then maybe move this to
sound/soc/intel/boards/Kconfig
I am not sure about the alsa-lib dependency, it's a bit odd, isn't it?
shouldn't this be handled via protocol versions? or a configuration
provided by alsa-lib somehow?
It's not about the protocol. It's about to move this type of information
to another place. I can remove the ALSA version sentence from the help,
because it's just a hint. I would like to create ucm2 configurations
based on this rather than the misused long card names.
I am with you on the idea, it's the transition that worries me. I guess
for a distro that would be fine, one would hope that there is a
communication between the alsa-lib and the kernel configurations parts,
but for a random user there's a chance that they would not select this
and not use ucm2 and vice versa.
it's also painful for kernel developers to rely on to-be-released
alsa-lib changes, we've been there with SOF and I don't know how many
times we had reports of issues related to alsa-lib setup problems. Here
it'd be worse since alsa-lib updates would need to be deployed on target
devices.
Again I am not against the idea, but anything we can do to reuse
friction during the transition will help a great deal.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
