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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 17905C433E0 for ; Thu, 14 Jan 2021 01:43:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CE97823435 for ; Thu, 14 Jan 2021 01:43:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728007AbhANBnM (ORCPT ); Wed, 13 Jan 2021 20:43:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727557AbhANB35 (ORCPT ); Wed, 13 Jan 2021 20:29:57 -0500 Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E60A5C0617A3 for ; Wed, 13 Jan 2021 17:29:16 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id 22so5083016qkf.9 for ; Wed, 13 Jan 2021 17:29:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9CU5hC/wv1WyG3qcAaf75yGzuAfWHeashTxgX7KjjpI=; b=K6Hq+G0LhXjQqO4H96lSva7ZtrmqncVNCsrUw1x3GpPYKTOu96SYHCMIGHB+UXhLT7 bnDVV7Da8nb5UKCBo98+d2ekTCz0M3i2QaCCdzfXsq43wqghTawUFI6qEMSurf+eEHDJ OTchATUo7k+/FaLZUw+1el0dBgnmhcosnM4NU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9CU5hC/wv1WyG3qcAaf75yGzuAfWHeashTxgX7KjjpI=; b=RLvxBYkzUGznmwi4u/GfyuhTY9CA0c9QjHngoIK80QK1bSkm0WqktvDknQm36YGVgN j81HuAkczjq/ijJHN71Bkfb1GpBzxbzaGwXoU7z5tLe5oLUnCRxZqScVkywlO4U92A4r T5S39f9+2h6Z0O9OG0Te08+l2c4t4QLfRgXpnPF0paM+v4YH9kFRlwur8H/r8Fleqq8/ RSRF0ZVHZCXaISmOtglsSmh5vg2jDlRugJnhyYeJQyC4ploOA9fQmUnQ8q64WkawssnV BseaN6aXHS2v5KCyEiIbixmDBE5/847mDwluLoDU5/djyCD9BGNfTUuvOkvH4onFZihZ 6ITA== X-Gm-Message-State: AOAM530pFKPc1Je7PNjj+4xcr3Aht+Jr9ki9h7rR2iC522ohO65qW7/0 TpbhvEd+QlInvXazf6v6vZ9HWPiewykVTQ2g1frlHA== X-Google-Smtp-Source: ABdhPJxWNm4eqecBXA5G0Ky7souL+BlfLXiDVYwNNhK8YLResag3hUy0NhhbANooMsLe/qYCoji4ZUpqlDe71lm1eT0= X-Received: by 2002:a25:adc2:: with SMTP id d2mr6962640ybe.75.1610587756217; Wed, 13 Jan 2021 17:29:16 -0800 (PST) MIME-Version: 1.0 References: <20210107154200.v4.1.I025fb861cd5fa0ef5286b7dce514728e9df7ae74@changeid> <20210107154200.v4.2.Ibe7d7d53c5b4fe72c60de90111ff763b53f38dbb@changeid> <161041827643.3661239.17919996906733477213@swboyd.mtv.corp.google.com> <161052058590.3661239.5654596152411573148@swboyd.mtv.corp.google.com> <161057967168.3661239.10329365279391431594@swboyd.mtv.corp.google.com> In-Reply-To: <161057967168.3661239.10329365279391431594@swboyd.mtv.corp.google.com> From: Philip Chen Date: Wed, 13 Jan 2021 17:29:05 -0800 Message-ID: Subject: Re: [PATCH v4 2/2] Input: cros-ec-keyb - Expose function row physical map to userspace To: Stephen Boyd Cc: LKML , Dmitry Torokhov , Douglas Anderson , Benson Leung , Enric Balletbo i Serra , Guenter Roeck , Lee Jones , linux-input@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 13, 2021 at 3:14 PM Stephen Boyd wrote: > > Quoting Philip Chen (2021-01-13 14:47:18) > > On Tue, Jan 12, 2021 at 10:49 PM Stephen Boyd wrote: > > > > > > Quoting Philip Chen (2021-01-12 15:55:28) > > > > On Mon, Jan 11, 2021 at 6:24 PM Stephen Boyd wrote: > > > > > > > > > > Quoting Philip Chen (2021-01-07 15:42:09) > > > > > > The top-row keys in a keyboard usually have dual functionalities. > > > > > > E.g. A function key "F1" is also an action key "Browser back". > > > > > > > > > > > > Therefore, when an application receives an action key code from > > > > > > a top-row key press, the application needs to know how to correlate > > > > > > the action key code with the function key code and do the conversion > > > > > > whenever necessary. > > > > > > > > > > > > Since the userpace already knows the key scanlines (row/column) > > > > > > associated with a received key code. Essentially, the userspace only > > > > > > needs a mapping between the key row/column and the matching physical > > > > > > location in the top row. > > > > > > > > > > > > This patch enhances the cros-ec-keyb driver to create such a mapping > > > > > > and expose it to userspace in the form of a function-row-physmap > > > > > > attribute. The attribute would be a space separated ordered list of > > > > > > row/column codes, for the keys in the function row, in a left-to-right > > > > > > order. > > > > > > > > > > > > The attribute will only be present when the device has a custom design > > > > > > for the top-row keys. > > > > > > > > > > Is it documented in Documentation/ABI/? > > > > Not yet. > > > > Is it proper to add the documentation to `testing/sysfs-driver-input-keyboard`? > > > > > > Somewhere in testing is fine. I'm not sure if it is a generic proprty > > > for all keyboards though? What's the path in sysfs? > > I wouldn't say it's generic. > > It is available in the keyboard device node only when the board has a > > custom top-row keyboard design. > > The path in sysfs is something like: > > /sys/class/input/input0/device/function_row_physmap, where input0 is > > cros_ec. > > I see that atkbd already has this so at least it would be common to some > sort of keyboard device. I'm not sure where to document it though. I see > that atkbd has a handful of undocumented sysfs attributes so adding all > of those may lead to a common path. At the least it sounds OK to have a > sysfs-driver-input-keyboard file if input folks are OK with it. Since there are other undocumented sysfs attributes for input/keyboard anyway, we should probably leave the documentation to another patch? For now, let's move to patch v5, where I've addressed all of the comments so far. Thanks.