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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id BAF64C77B73 for ; Thu, 20 Apr 2023 14:29:03 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id CC903EB8; Thu, 20 Apr 2023 16:28:10 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz CC903EB8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1682000940; bh=3QOLUJB5tld9SqT9wFvg7zDbhmI49/rj1VarRdgDMmc=; h=Date:From:To:Subject:In-Reply-To:References:CC:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=qF4KhLakA0SA3t19Inx610jgjHO/g4oy1AKDg3n8rzrmwliJknY1wY1xmF4lauIZ6 CJCSSuFdQQPbs3clRB44LTxG26r8I9Oe5gKYnFlLCJOiEv1gp+F8QyOPAkF5tCbloR flhLaPCySqZbJCIl3euJCGY9QRYDY3AWkU1rzCDI= Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id 71FD6F80155; Thu, 20 Apr 2023 16:27:44 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id BD7AEF80155; Thu, 20 Apr 2023 16:27:40 +0200 (CEST) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 9CA07F800F8 for ; Thu, 20 Apr 2023 16:27:36 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 9CA07F800F8 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key, unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=TBmIM9bC; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=os0Kv0Ln Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 1A6471FDB3; Thu, 20 Apr 2023 14:27:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1682000856; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=e5NC2zzcdmpwlRy7BZWyF3HkwJ13f3gTw/lOY44WV2w=; b=TBmIM9bCvg3sLxmyeSHO/QXiMzA1azj352Z15UE01Z43+BiJsejjbXoD6n5seRfU5luDcZ 80mERfFttqWrMRNA/P2kcyx7ELfowJ0eNzAUOZGo/PrPwwtHCXQ8sTBO03U1r9hbbnLzr8 y7evWl4bTJHR841Gnl3i6RxPPJZX8SY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1682000856; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=e5NC2zzcdmpwlRy7BZWyF3HkwJ13f3gTw/lOY44WV2w=; b=os0Kv0LnSAQ/RYoz3qf6AmAzjytYTREPAVmD46T2YfH8Kvmq9853d8JNCwwcTliDroIewg MfvmdToh2YzVSBBA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id EBC111333C; Thu, 20 Apr 2023 14:27:35 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id zUFhONdLQWRuOwAAMHmgww (envelope-from ); Thu, 20 Apr 2023 14:27:35 +0000 Date: Thu, 20 Apr 2023 16:27:35 +0200 Message-ID: <87leimtyqw.wl-tiwai@suse.de> From: Takashi Iwai To: Oswald Buddenhagen Subject: Re: [RFC PATCH] docs: sound: kernel-api: writing-an-alsa-driver.rst: add FIXMEs In-Reply-To: References: <20230405201220.2197878-1-oswald.buddenhagen@gmx.de> <87sfddv7e4.wl-tiwai@suse.de> <87wn26u32c.wl-tiwai@suse.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Message-ID-Hash: R2PZ7TZE4KRSOQ4F2Y3E4W5IDWXQXXP5 X-Message-ID-Hash: R2PZ7TZE4KRSOQ4F2Y3E4W5IDWXQXXP5 X-MailFrom: tiwai@suse.de X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-alsa-devel.alsa-project.org-0; header-match-alsa-devel.alsa-project.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: alsa-devel@alsa-project.org X-Mailman-Version: 3.3.8 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, 20 Apr 2023 15:44:50 +0200, Oswald Buddenhagen wrote: > > On Thu, Apr 20, 2023 at 02:54:19PM +0200, Takashi Iwai wrote: > > On Thu, 20 Apr 2023 14:47:11 +0200, Oswald Buddenhagen wrote: > >> On Thu, Apr 06, 2023 at 08:42:27AM +0200, Takashi Iwai wrote: > >> > On Wed, 05 Apr 2023 22:12:20 +0200, Oswald Buddenhagen wrote: > >> >> The ``name`` is the name identifier string. Since ALSA 0.9.x, the > >> >> control name is very important, because its role is classified from > >> >> its name. > >> >> +// This is a questionable design, IMO. Why user-space heuristics when > >> >> +// the driver could set the roles/capabilities? This would avoid > >> >> +// problems like the Tone Control sliders (unlike the switch?!) being > >> >> +// misclassified as applying also to capture. > >> > > Why this has to be discussed here and now...? > >> > why not? > > > > Because it is the already defined rule, and you're complaining the > > documentation. You are free to start a new discussion, but not it > > shouldn't be along with the documentation patch at all. > > > this is a "various questions about the documentation" patch/thread. i > can't think of a better place to discuss/document design choices. But why this has to be buried in the middle of a patch containing lots of other changes...? Better to split out and start a new thread. > > >> > It's the thing that was *defined* over two decades ago. > >> > that may be so, but this doesn't explain anything. > >> it's a somewhat surprising choice, and it does in fact sometimes cause > >> problems. so at least it should be thoroughly explained. > > > > Again, you're barking at a wrong place. The whole control name ruling > > is explained in another document; there is another document covering > > control name rules. > > > there is the control-names.rst document. > if you agree, i'd actually move the entire "Control Names" section > into it, to avoid redundancy. I don't mind too much, but holding a brief description is always nice, better than just mentioning another reference. You can refer to the other document for details, of course, though. > but none of that explains the design choice. The design choice was a looooong history, ca 25 years ago. > two questions require an answer, imo: a) why was is done this way and > b) do you still consider it the right choice? IIRC, this was a result after struggles with the structured control implementations. It became too complex, and the plain array with string representation can cover all complexity, while it still allows the grouping in user-space side. Again, the choice was done in a quarter century ago, and if you change it, you'll certainly break the whole things badly. We must keep the compatibility. Takashi