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

[Jaroslav Kysela]

Dne 25. 10. 19 v 18:11 Takashi Iwai napsal(a):
> On Fri, 25 Oct 2019 16:39:44 +0200,
> Jaroslav Kysela wrote:
>>
>> Dne 25. 10. 19 v 16:28 Takashi Iwai napsal(a):
>>> On Fri, 25 Oct 2019 16:18:20 +0200,
>>> Jaroslav Kysela wrote:
>>>>
>>>> Dne 25. 10. 19 v 16:06 Takashi Iwai napsal(a):
>>>>> On Fri, 25 Oct 2019 15:57:50 +0200,
>>>>> Jaroslav Kysela wrote:
>>>>>>
>>>>>> Dne 25. 10. 19 v 14:38 Takashi Iwai napsal(a):
>>>>>>> On Fri, 25 Oct 2019 14:30:38 +0200,
>>>>>>> Jaroslav Kysela wrote:
>>>>>>>>
>>>>>>>> There is an inconsistency in the names for the HDMI/DP Jack control
>>>>>>>> names between some ASoC drivers and the HDA HDMI driver which
>>>>>>>> introduced this naming in 2011.
>>>>>>>>
>>>>>>>> There might be an impact for the user space (UCM). I will fix
>>>>>>>> the UCM configurations when this patch is applied.
>>>>>>>>
>>>>>>>> Signed-off-by: Jaroslav Kysela <perex at perex.cz>
>>>>>>>> Cc: Mark Brown <broonie at kernel.org>
>>>>>>>> Cc: Pierre-Louis Bossart <pierre-louis.bossart at linux.intel.com>
>>>>>>>
>>>>>>> Yes, that's a known problem, and I left them so far just for keeping
>>>>>>> the already existing stuff working.
>>>>>>>
>>>>>>> Won't this break the current Chromebooks user-space?
>>>>>>
>>>>>> I would really expect to upgrade UCM configs for the recent kernels in
>>>>>> this case. I believe, those sort of issues are better to fix early
>>>>>> than lately. I know, the transition might cause a little issues, but
>>>>>> usually "do upgrade answer" will help. I don't think that we speak
>>>>>> about a large group of users here.
>>>>>
>>>>> Well, that's obviously against our dont-breaking-user-space rule.
>>>>> The UCM profiles have been widely used on Chromebooks, and they can't
>>>>> upgrade easily.
>>>>>
>>>>> So, I believe this is a case where we have to live with messes.
>>>>
>>>> If we speak about Google's kernels, they can apply a revert (depends
>>>> on their upgrade/maintenance policy). If users use the standard Linux
>>>> distributions, then we are fine, don't we?
>>>
>>> No, we can't break the already existing user-space.  That's what Linus
>>> suggested repeatedly over years, too.
>>>
>>>> I would make an exception for the dont-breaking-user-space policy in
>>>> this case. I am sure that the UCM configs will stabilize quickly. And
>>>> this bad jack name is against our control name policy. It's just a
>>>> bug.
>>>
>>> There is no exception for that, it's a so simple rule.  If something
>>> gets *practically* broken by the kernel, it's no-go.  User-space is
>>> user-space, and it doesn't matter whether it's upstream or not.
>>>
>>> And, even if everything is upstream, imagine that user installs two
>>> different kernels, and switches with each other occasionally for
>>> whatever reason.  The UCM upgrade solution won't work, either.
>>
>> It's the corner case with the really low impact. Users do not do this
>> usually. Ok, I will be silent again. It seems that we cannot get an
>> agreement on this simple thing. I just prefer the fix rather than
>> nothing.
> 
> I'd love to fix things, too, of course.  But we need changing our
> mindset: what we - the kernel devs - can control is only inside the
> kernel.  Even the upstream alsa-lib and UCM profiles are merely
> reference implementations.

You speak about ChromeOS not Linux here.. Anyway, I wanted to cleanup the 
driver names like 'sof-skl_hda_card' (mixed - and _). It seems that it's just 
waste of time, because you'll argue that the user-space is incompatible, too.

So every time when we have wrong string in the kernel, we cannot change it, 
because the user-space. Okay, that's imperfect world. We're being driven with 
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.

I would be really curious what will happen when we change those strings ;-)

		Nice weekend to all,
					Jaroslav

-- 
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.