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

[Takashi Iwai]

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.


thanks,

Takashi