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

On Wed, Jan 13, 2021 at 3:14 PM Stephen Boyd [off-list ref] wrote:

Quoting Philip Chen (2021-01-13 14:47:18)

quoted

On Tue, Jan 12, 2021 at 10:49 PM Stephen Boyd [off-list ref] wrote:

quoted

Quoting Philip Chen (2021-01-12 15:55:28)

quoted

On Mon, Jan 11, 2021 at 6:24 PM Stephen Boyd [off-list ref] wrote:

quoted

Quoting Philip Chen (2021-01-07 15:42:09)

quoted

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.