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 35D89C001DC for ; Mon, 31 Jul 2023 12:17:24 +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 71BC3828; Mon, 31 Jul 2023 14:16:32 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 71BC3828 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1690805842; bh=i13HU39SCKegCaDPfNGaw3W3rtpk9GCc6IS+sTTxyrs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=V8qTz2rGHdvJH6tPT3qgQRPAJMKujjokYPNICtxeTDzosRqDs7eEydOE08Jtf6M53 VeWayDxIOM9rY+RwHWLdJNQAw0Ewt0+LfUq3FJlA3ky6/k1CHydgmnCZ9aiWoFFtog 8g8LyfJOOOdmN76ZXszJnrbRe8v5lZGxXV2zfncw= Received: by alsa1.perex.cz (Postfix, from userid 50401) id 9B2BAF80544; Mon, 31 Jul 2023 14:16:04 +0200 (CEST) Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id 0EE4EF80153; Mon, 31 Jul 2023 14:16:04 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 0400EF8016D; Mon, 31 Jul 2023 14:16:00 +0200 (CEST) Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) (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 AAFCBF8015B for ; Mon, 31 Jul 2023 14:15:54 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz AAFCBF8015B 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=TO18gOmR; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=IbQlAEuO 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-out1.suse.de (Postfix) with ESMTPS id 24713222F0; Mon, 31 Jul 2023 12:15:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1690805754; 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=AqmPhS5KInYADGWgPBNsXftE0bzt9Z1q7QgSwcn97mQ=; b=TO18gOmRAlHE3RaIgpjjO8eYSB09JgL+NveRtWlEg8Cv1Q7VL7cjxpTl16u/w7EvX5AcZF eR2AHGAr+VG/FcNkVDlwlOphqFsvo6HpdG9pcBC98E8mCgnDg5Q2dItRp6fVVZPfUlIgDS Iy/YyvlScWLTyfe2h00f0NiY1SJ6Hog= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1690805754; 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=AqmPhS5KInYADGWgPBNsXftE0bzt9Z1q7QgSwcn97mQ=; b=IbQlAEuORlY6Fh2HbYqru/0BqtX6JF/K5Z0n9xY9HRoLC9b9CFGX5Bq+JqsDDrlXURDNyd 3mp2A4lxYyz5MnAA== 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 CEFF01322C; Mon, 31 Jul 2023 12:15:53 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 8pdJMfmlx2QcFAAAMHmgww (envelope-from ); Mon, 31 Jul 2023 12:15:53 +0000 Date: Mon, 31 Jul 2023 14:15:53 +0200 Message-ID: <87tttkjmyu.wl-tiwai@suse.de> From: Takashi Iwai To: Marek Vasut Cc: Dmitry Torokhov , Jeff LaBundy , linux-input@vger.kernel.org, Uwe =?ISO-8859-1?Q?Klein?= =?ISO-8859-1?Q?e-K=F6nig?= , Frieder Schrempf , Manuel Traut , Thierry Reding , linux-pwm@vger.kernel.org, alsa-devel@alsa-project.org, Jaroslav Kysela , Takashi Iwai Subject: Re: [PATCH] Input: pwm-beeper - Support volume setting via sysfs In-Reply-To: <63adce9a-df65-b462-9055-0ece5216d680@denx.de> References: <20230512185551.183049-1-marex@denx.de> <0ef98ec1-6191-c72e-2362-310db7f09b84@denx.de> <06379f26-ab24-85f9-783f-0c49d4291b23@denx.de> <873514d2ju.wl-tiwai@suse.de> <63adce9a-df65-b462-9055-0ece5216d680@denx.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: DHY7UGR2RHCX6IV6G5DGUGCC47X6LXON X-Message-ID-Hash: DHY7UGR2RHCX6IV6G5DGUGCC47X6LXON 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 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 Mon, 31 Jul 2023 13:49:46 +0200, Marek Vasut wrote: > > On 7/31/23 08:21, Takashi Iwai wrote: > > On Mon, 31 Jul 2023 07:36:38 +0200, > > Dmitry Torokhov wrote: > >> > >> On Sat, May 13, 2023 at 11:02:30PM +0200, Marek Vasut wrote: > >>> On 5/13/23 03:51, Marek Vasut wrote: > >>>> On 5/13/23 03:12, Jeff LaBundy wrote: > >>>>> Hi Marek, > >>>> > >>>> Hi, > >>>> > >>>>> On Fri, May 12, 2023 at 08:55:51PM +0200, Marek Vasut wrote: > >>>>>> The PWM beeper volume can be controlled by adjusting the PWM duty cycle, > >>>>>> expose volume setting via sysfs, so users can make the beeper quieter. > >>>>>> This patch adds sysfs attribute 'volume' in range 0..50000, i.e. from 0 > >>>>>> to 50% in 1/1000th of percent steps, this resolution should be > >>>>>> sufficient. > >>>>>> > >>>>>> The reason for 50000 cap on volume or PWM duty cycle is because > >>>>>> duty cycle > >>>>>> above 50% again reduces the loudness, the PWM wave form is inverted wave > >>>>>> form of the one for duty cycle below 50% and the beeper gets quieter the > >>>>>> closer the setting is to 100% . Hence, 50% cap where the wave > >>>>>> form yields > >>>>>> the loudest result. > >>>>>> > >>>>>> Signed-off-by: Marek Vasut > >>>>>> --- > >>>>>> An alternative option would be to extend the userspace input > >>>>>> ABI, e.g. by > >>>>>> using SND_TONE top 16bits to encode the duty cycle in 0..50000 > >>>>>> range, and > >>>>>> bottom 16bit to encode the existing frequency in Hz . Since frequency in > >>>>>> Hz is likely to be below some 25 kHz for audible bell, this fits > >>>>>> in 16bits > >>>>>> just fine. Thoughts ? > >>>>>> --- > >>>>> > >>>>> Thanks for the patch; this seems like a useful feature. > >>>>> > >>>>> My first thought is that 50000 seems like an oddly specific limit to > >>>>> impose > >>>>> upon user space. Ideally, user space need not even care that the > >>>>> beeper is > >>>>> implemented via PWM and why 50000 is significant. > >>>>> > >>>>> Instead, what about accepting 0..255 as the LED subsystem does for > >>>>> brightness, > >>>>> then map these values to 0..50000 internally? In fact, the leds-pwm > >>>>> driver > >>>>> does something similar. > >>>> > >>>> The pwm_set_relative_duty_cycle() function can map whatever range to > >>>> whatever other range of the PWM already, so that's not an issues here. > >>>> It seems to me the 0..127 or 0..255 range is a bit too limiting . I > >>>> think even for the LEDs the reason for that limit is legacy design, but > >>>> here I might be wrong. > >>>> > >>>>> I'm also curious as to whether this function should be a rogue sysfs > >>>>> control > >>>>> limited to this driver, or a generic operation in input. For > >>>>> example, input > >>>>> already allows user space to specify the magnitude of an FF effect; > >>>>> perhaps > >>>>> something similar is warranted here? > >>>> > >>>> See the "An alternative ..." part above, I was wondering about this too, > >>>> whether this can be added into the input ABI, but I am somewhat > >>>> reluctant to fiddle with the ABI. > >>> > >>> Thinking about this further, we could try and add some > >>> > >>> EV_SND SND_TONE_WITH_VOLUME > >>> > >>> to avoid overloading EV_SND SND_TONE , and at the same time allow the user > >>> to set both frequency and volume for the tone without any race condition > >>> between the two. > >>> > >>> The EV_SND SND_TONE_WITH_VOLUME would still take one 32bit parameter, except > >>> this time the parameter 16 LSbits would be the frequency and 16 MSbits would > >>> be the volume. > >>> > >>> But again, here I would like input from the maintainers. > >> > >> Beeper was supposed to be an extremely simple device with minimal > >> controls. I wonder if there is need for volume controls, etc, etc are we > >> not better moving it over to the sound subsystem. We already have: > >> > >> sound/drivers/pcsp/pcsp.c > >> > >> and > >> > >> sound/pci/hda/hda_beep.c > >> > >> there, can we have other "advanced" beepers there as well? Adding sound > >> maintainers to CC... > > > > I don't mind it put to sound/*. But, note that pcsp.c you pointed in > > the above is a PCM tone generator driver with a PC beep device, and it > > provides the normal SND_BEEP input only for compatibility. > > > > Indeed there have been already many sound drivers providing the beep > > capability, and they bind with the input device using SND_BEEP. And, > > for the beep volume, "Beep Playback Volume" mixer control is provided, > > too. > > Uh, I don't need a full sound device to emit beeps, that's not even > possible with this hardware. Heh, I also don't recommend that route, either :) (Though, it must be possible to create a sound device with that beep control in theory) > I only need to control loudness of the > beeper that is controlled by PWM output. That's why I am trying to > extend the pwm-beeper driver, which seems the best fit for such a > device, it is only missing this one feature (loudness control). So the question is what's expected from user-space POV. If a more generic control of beep volume is required, e.g. for desktop-like usages, an implementation of sound driver wouldn't be too bad. OTOH, for other specific use-cases, it doesn't matter much in which interface it's implemented, and sysfs could be an easy choice. And, IMO, extending the SND_BEEP with a volume value doesn't sound like a good idea. thanks, Takashi