Dne 08. 04. 21 v 11:43 Jaroslav Kysela napsal(a):
There are several strings which are describing the card. As time goes, we have new universal drivers which probe components in a way, which is disassociated from the card structure (ASoC). Also, some drivers may require to select another firmware depending on the specific platform using udev. The new firmware may change the sound card behaviour.
This patch allows flexible modifications of the card description from the user space to handle the specific boot / plug-in settings.
The original discussion went to different forks, but I'd like summarize some points:
1) those runtime changes may be intrusive 2) even if we allow to change those strings, we should preserve the original 3) generate change events
I hope that we all see the flexibility to change those strings via udev. The nice thing is that we can write to those sysfs attributes before the _control device file_ is created by udev (thus we are pretty sure, that no applications are using this information (if I omit the additional proc and sysfs resources).
It seems to me, that we may just add a policy how to handle those card identification changes. This policy may be controlled using a module parameter (runtime), kernel configuration option (compiled default). The policies will be 'allow changes' and 'disallow changes' so distributions or users may be forced to explicitly enable this behaviour. When all sysfs changes are finished, the udev rules may just set "do not allow other changes" via an additional sysfs sound card attribute (write once) to prevent user errors. Or we may apply the 'write once' mechanism for all strings separately. We should disallow to change the card identification after this point.
Regarding the original value preservation - the udev can save the original strings to it's device environment variables for the later usage. We may handle this in the kernel. but I see the code reduction with this idea and the use will be rate (alsa-info script may be extended to extract this info from the udev database).
The change events are not necessary with this policy. The card identification is supposed to be changed only via udev before any application is active.
Jaroslav