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