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@xxxxxxxx> > >>>>>> Cc: Mark Brown <broonie@xxxxxxxxxx> > >>>>>> Cc: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> > >>>>> > >>>>> 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
