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@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.
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@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
