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@perex.cz > Cc: Mark Brown broonie@kernel.org > Cc: Pierre-Louis Bossart pierre-louis.bossart@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