[alsa-devel] [PATCH] ASoC: change 'HDMI/DP, pcm=' to 'HDMI/DP, pcm=' Jack control names

[Jaroslav Kysela]

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 at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.