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.
