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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2EA2C64EC4 for ; Sun, 19 Feb 2023 15:30:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230082AbjBSPaN (ORCPT ); Sun, 19 Feb 2023 10:30:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38088 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229870AbjBSPaK (ORCPT ); Sun, 19 Feb 2023 10:30:10 -0500 Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E3279FF01; Sun, 19 Feb 2023 07:30:07 -0800 (PST) Date: Sun, 19 Feb 2023 15:30:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=connolly.tech; s=protonmail; t=1676820605; x=1677079805; bh=ucl/nUvzkNkdPDWvkaASa6MWLaX46zxlHKTO/1V4RKU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=goDUvpW53D4mdq1g+VaJDFpGQeJybPvKJEcVXlBTW0uERq8xwOrrAToaoWbXx1swG OymG/2k/6PbS0AODQ1dt2FKsEu7k2qOGVOlmlVy9bP0NsztaRpHYJWeySPGycuBlyP lWbPJfTArnYbdY75Mkuli4p24Uwjyjms2HLxa+hE= To: Gergo Koteles , Pavel Machek From: Caleb Connolly Cc: Dmitry Torokhov , Andy Gross , Bjorn Andersson , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Jiri Kosina , Benjamin Tissoires , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v2 3/3] arm64: dts: qcom: sdm845-oneplus: add tri-state-key Message-ID: In-Reply-To: <007239f0-1b13-77b9-0d9c-d68747e20331@irl.hu> References: <20230209232556.91554-1-soyer@irl.hu> <007239f0-1b13-77b9-0d9c-d68747e20331@irl.hu> Feedback-ID: 10753939:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16/02/2023 03:32, Gergo Koteles wrote: > Hi, > >> >> >> On 11/02/2023 16:40, Pavel Machek wrote: >>> Hi! >>> >>>> +++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi >>>> @@ -52,6 +52,43 @@ key-vol-up { >>>> =09=09}; >>>> =09}; >>>> >>>> +=09tri-state-key { >>>> +=09=09compatible =3D "gpio-keys"; >>>> +=09=09label =3D "Tri-state key"; >>>> +=09=09pinctrl-names =3D "default"; >>>> +=09=09pinctrl-0 =3D <&tri_state_key_default>; >>>> +=09=09state-top { >>>> +=09=09=09label =3D "Tri-state key top"; >>> >>> "top/middle" is not too useful. Do we need the label at all? If so, >>> should it say "loud/vibrations only/mute"? >> >> "mute", "vibrate" and "ring" sound good to me. >> > > OnePlus uses the silent/vibrate/ring, iPhone the silent/ring names. > Maybe silent/vibrate/ring are more familiar. > > Adding labels can document these modes here. > Should we also document these in input-event-codes.h? Maybe it would be best to define macros for these rather than leave them as magic numbers > #define ABS_SND_PROFILE=09=090x22 /* 0 =3D silent; 1 =3D vibrate; 2 =3D r= ing */ #define ABS_SND_PROFILE_SILENT=090 #define ABS_SND_PROFILE_VIBRATE=091 #define ABS_SND_PROFILE_RING=092 > > > Thanks, > Gergo > >> Although it would be nice if users can easily map the physical key >> position to the action when viewing the input device or remapping the >> key in userspace. >> >> Do you have any ideas or recommendations on how to do this? >>> >>> BR, >>> =09=09=09=09=09=09=09=09Pavel >> >> -- >> Kind Regards, >> Caleb >> > -- Kind Regards, Caleb