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

[Takashi Iwai]

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.


thanks,

Takashi