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
--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
