Hi Dmitry, Thanks for reviewing my patch over the holiday season. Please check my CIL. On Mon, Dec 28, 2020 at 10:18 PM Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > > Hi Philip, > > On Mon, Dec 21, 2020 at 05:47:57PM -0800, Philip Chen wrote: > > This patch adds a new property `google,custom-keyb-top-row` to the > > device tree for the custom keyboard top row design. > > Why don't we use the property we have for the same purpose in atkbd.c? > I.e. function-row-physmap? > Because this property serves a different purpose than function-row-physmap. `function-row-physmap` basically links the scancode to the physical position in the top row. `google,custom-keyb-top-row` aims at specifying the board-specific keyboard top row design associated with the action codes. In x86 path, the board-specific keyboard top row design associated with the action codes is exposed from coreboot to kernel through "linux,keymap" acpi table. When coreboot generates this acpi table, it asks EC to provide this information, since we add the board-specific top-row-design in EC codebase. (E.g. https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/main/board/jinlon/board.c#396) In ARM, we don't plan to involve EC in the vivaldi support stack. So `google,custom-keyb-top-row` DT property is our replacement for the board-specific top-row-design in x86 EC codebase. > Also, instead of specifying keycodes in this array we should use > combination of row and column identifying keys, like this: > > function-row-physmap = < > MATRIX_KEY(0x00, 0x02, KEY_F1), > MATRIX_KEY(0x03, 0x02, KEY_F2), > ... > >; This mapping between row/column to function keycode is fixed for all Chrome OS devices. So we don't really need to host this information in DT. Instead, I plan to hardcode this information in cros_ec_keyb.c. (Please see the array "top_row_key_pos[]" in my next patch: "[2/3] Input: cros_ec_keyb - Support custom top-row keys".) The only thing that could make the function-row-physmap file different among boards is the number of top row keys. But this information can be derived from the length of `google,custom-keyb-top-row`. So we don't need a separate DT property for it. Thanks. > > > Note that the last item in the triple is purely cosmetic in this case, > you can change it to 0. It is row and column that are important. > > Then the mapping will work properly even if we change keymap, for > example from userspace. > > Thanks. > > -- > Dmitry
