From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 44CA2CA9EA0 for ; Fri, 25 Oct 2019 16:12:17 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DDA8D21872 for ; Fri, 25 Oct 2019 16:12:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="Lh1nZS8D" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DDA8D21872 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id B57961841; Fri, 25 Oct 2019 18:11:23 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz B57961841 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1572019933; bh=Z3rqAFTbejTR/05Nn1fdcogcY8ctFEH9P9zq7t0PYhA=; h=Date:From:To:In-Reply-To:References:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=Lh1nZS8DTur1J5+6zEWQrCNM8/R6wT1lk63qwMncGiVnCK+aYLrpRWlMkCQEYeyr/ EH/LVKqUJPsCKL2OhKRARs+VbzAG9d6F2ff4EYNilE8o0F2UFMht40m/rNbCN6Pve1 xWpNb/P9/evhkeWoi1qUf7tGWwxQYf6fH08PtKao= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 275FCF80112; Fri, 25 Oct 2019 18:11:23 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 03D61F8036F; Fri, 25 Oct 2019 18:11:22 +0200 (CEST) Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 47138F802A0 for ; Fri, 25 Oct 2019 18:11:18 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 47138F802A0 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 55EBEB692; Fri, 25 Oct 2019 16:11:18 +0000 (UTC) Date: Fri, 25 Oct 2019 18:11:18 +0200 Message-ID: From: Takashi Iwai To: Jaroslav Kysela In-Reply-To: <83e4dc16-07e7-aafb-db43-01a89e31270b@perex.cz> References: <20191025123038.19728-1-perex@perex.cz> <9403a6a7-9b7e-c2a4-5acf-50d6cbaea7c7@perex.cz> <83e4dc16-07e7-aafb-db43-01a89e31270b@perex.cz> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: ALSA development , Mark Brown , Pierre-Louis Bossart Subject: Re: [alsa-devel] [PATCH] ASoC: change 'HDMI/DP, pcm=' to 'HDMI/DP, pcm=' Jack control names X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" 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 > >>>>>> Cc: Mark Brown > >>>>>> Cc: Pierre-Louis Bossart > >>>>> > >>>>> 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@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel