Dne 25. 10. 19 v 20:02 Kai Vehmanen napsal(a):
Hi Jaroslav and all,
On Fri, 25 Oct 2019, Jaroslav Kysela wrote:
the single user. Another problem is that we are not able to review all those mistakes at the merge time. It is not a complain but a true fact.
but the strings are in kernel patches, so even if all UCM files don't go through the list, we can always review when the strings are added in kernel, right?
My point is that we already did this incomplete review (the wrong strings are in the current kernel). We cannot prevent to avoid those code merges, we are just human. I just don't think that the driver / control names should be part of the don't-break-the-userspace policy.
I would be really curious what will happen when we change those strings ;-)
I can share some experiences that happen on Linux distros with Pulseaudio:
- if mixer control name is changed/missing that us used in a UCM enable sequence, the enable sequence will fail and PA will not choose that device -> e.g. when wrong HDMI control names are in the UCM file, HDMI output stops working
- if mixer control for a Jack is changed, PA will not listen for ALSA kctl events -> HDMI connection is silently missed and HDMI is not listed as a possible output
.. i.e. in both cases HDMI is essentially broken if you update to a kernel that updates the strings but don't update user-space in sync.
Yes, it's true. But usually, users do only upgrade. If we resolve the UCM configs before the kernel change, the impact is just very low.
I wonder if one option would be to expose "legacy string" aliases, allowing to make changes but keep existing user-space happy. With my HDMI codec change, the controls are simply different, so this was not an option and I had to opt for keeping the whole driver around.
It seems that we may need to add conditions to the UCM syntax. There are several ways to do it. For your specific purpose it may look like "if the control exist, use this config" or so.
Another approach might be to add something to the decision code which top UCM config file should be loaded. Actually, we rely on the card name / long_name only. It seems that the probe might be extended here.
Jaroslav