Re: [PATCH v4 2/2] Input: cros-ec-keyb - Expose function row physical map to userspace

From: Philip Chen <philipchen@chromium.org>
To: Stephen Boyd <swboyd@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Douglas Anderson <dianders@chromium.org>,
	Benson Leung <bleung@chromium.org>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Guenter Roeck <groeck@chromium.org>,
	Lee Jones <lee.jones@linaro.org>,
	linux-input@vger.kernel.org
Subject: Re: [PATCH v4 2/2] Input: cros-ec-keyb - Expose function row physical map to userspace
Date: Wed, 13 Jan 2021 17:29:05 -0800	[thread overview]
Message-ID: <CA+cxXhmV_RxLupD18aOxLwaGGKSxihTY8ZZvQKzdd-dsYYf5dQ@mail.gmail.com> (raw)
In-Reply-To: <161057967168.3661239.10329365279391431594@swboyd.mtv.corp.google.com>

On Wed, Jan 13, 2021 at 3:14 PM Stephen Boyd <swboyd@chromium.org> wrote:
>
> Quoting Philip Chen (2021-01-13 14:47:18)
> > On Tue, Jan 12, 2021 at 10:49 PM Stephen Boyd <swboyd@chromium.org> wrote:
> > >
> > > Quoting Philip Chen (2021-01-12 15:55:28)
> > > > On Mon, Jan 11, 2021 at 6:24 PM Stephen Boyd <swboyd@chromium.org> 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.