On Sat, 26 Oct 2019 19:11:27 +0200, Jaroslav Kysela wrote: > > Dne 26. 10. 19 v 9:37 Takashi Iwai napsal(a): > > On Fri, 25 Oct 2019 23:03:26 +0200, > > Jaroslav Kysela wrote: > >> > >> Dne 25. 10. 19 v 20:02 Kai Vehmanen napsal(a): > >>> Hi Jaroslav and all, > >>> > >>> On Fri, 25 Oct 2019, Jaroslav Kysela wrote: > >>> > >>>> 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. > >>> > >>> but the strings are in kernel patches, so even if all UCM files don't > >>> go through the list, we can always review when the strings are added > >>> in kernel, right? > >> > >> My point is that we already did this incomplete review (the wrong > >> strings are in the current kernel). We cannot prevent to avoid those > >> code merges, we are just human. I just don't think that the driver / > >> control names should be part of the don't-break-the-userspace policy. > > > > It's a similar situation like the long-time discussion of tracing: > > when the kernel broke latencytop by changing the tracing format, we > > had to revert it in the end although the tracing format itself isn't > > strictly a "standard kernel ABI". The consensus is: if upgrading the > > kernel breaks anything *significant*, it's a regression and no-go. > > It's not about whether it's a part of ABI or not. > > > > In our particular case, the strings you wanted to fix are the ones > > that are actually hard-coded by the UCM profiles that are known to be > > really used on major systems. That's the only reason of NAK. If it > > were for some other minor kcontrol elements, it would have been OK. > > > > Kai's work to integrate SOF to the legacy HDMI driver would be also OK > > because it provides the compatibility mode. That is, we have some > > excuse that it's not us but users (distros) who actually breaks by > > choosing the kernel configuration explicitly (and even there can be a > > workaround with a module option). > > We can add another kernel option for this fix, too. If you like to move > in this direction, I'll modify my patch. I don't think it's worth for that. With Kai's patch set, we're going to move (back) to the legacy HDMI codec driver in most cases, so these strings will be specifically to the SST driver -- which are used by only limited number of devices like Chromebook or such. That said, if the reason for the change is just about consistency, the best recipe is to forget it. > The question is, if the kernel should provide a hint to the user space > (UCM), that something *significant* changed. Perhaps, the component > field in the control API might be used for this purpose as I already > proposed. In this way, we can support both kernels (with old and new > control names). I'm afraid that the current UCM profile cannot handle any extension as of now. We may need to introduce some incompatible extensibility at first to UCM profile syntax. This can be a good topic for the next meeting. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
