| Message ID | 20201221174751.1.I025fb861cd5fa0ef5286b7dce514728e9df7ae74@changeid |
|---|---|
| State | New |
| Headers | show |
| Series | [1/3] dt-bindings: input: cros-ec-keyb: Add a new property | expand |
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? 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), ... >; 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
On Sat, Jan 02, 2021 at 11:39:34AM -0800, Philip Chen wrote: > 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@gmail.com> 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. I disagree with this decision. We already have "linux,keymap" property that is supposed to hold accurate keymap for the device in question, there should be no need to introduce yet another property to adjust the keymap to reflect the reality. If a device uses "non classic" ChromeOS top row it should not be using the default keymap from arch/arm/boot/dts/cros-ec-keyboard.dtsi but supply its own. You can consider splitting the keymap into generic lower portion and the top row and moving them into an .h file so they can be easily reused. > > > 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. *for now* The mapping for the rest of the keyboard has also stayed static, but we still did not hardcode this information in the driver but rather used DT property to pass it into the kernel. > 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. I am sorry, but I must insist. We need to have: - accurate keymap in linux,keymap property - a separate property describing location of top row keys in terms of rows and columns (whether we reuse MATRIX_KEY or define another macro I do not really care). Thanks. -- Dmitry
Hi Dmitry, I see. I'll update these patch sets shortly based on your suggestion. Thanks. On Sat, Jan 2, 2021 at 1:04 PM Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > > On Sat, Jan 02, 2021 at 11:39:34AM -0800, Philip Chen wrote: > > 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@gmail.com> 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. > > I disagree with this decision. We already have "linux,keymap" property > that is supposed to hold accurate keymap for the device in question, > there should be no need to introduce yet another property to adjust the > keymap to reflect the reality. If a device uses "non classic" ChromeOS > top row it should not be using the default keymap from > arch/arm/boot/dts/cros-ec-keyboard.dtsi but supply its own. You can > consider splitting the keymap into generic lower portion and the top row > and moving them into an .h file so they can be easily reused. > > > > > > 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. > > *for now* The mapping for the rest of the keyboard has also stayed > static, but we still did not hardcode this information in the driver but > rather used DT property to pass it into the kernel. > > > 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. > > I am sorry, but I must insist. We need to have: > > - accurate keymap in linux,keymap property > - a separate property describing location of top row keys in terms of > rows and columns (whether we reuse MATRIX_KEY or define another macro > I do not really care). > > Thanks. > > -- > Dmitry
Hi Dmitry, On Sun, Jan 3, 2021 at 2:48 PM Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > > Hi Philip, > > On Sat, Jan 02, 2021 at 10:11:21PM -0800, Philip Chen wrote: > > Hi Dmitry, > > > > I have one more question below. > > Could you take a look? > > > > On Sat, Jan 2, 2021 at 8:53 PM Philip Chen <philipchen@chromium.org> wrote: > > > > > > Hi Dmitry, > > > > > > I see. > > > I'll update these patch sets shortly based on your suggestion. > > > Thanks. > > > > > > On Sat, Jan 2, 2021 at 1:04 PM Dmitry Torokhov > > > <dmitry.torokhov@gmail.com> wrote: > > > > > > > > On Sat, Jan 02, 2021 at 11:39:34AM -0800, Philip Chen wrote: > > > > > 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@gmail.com> 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. > > > > > > > > I disagree with this decision. We already have "linux,keymap" property > > > > that is supposed to hold accurate keymap for the device in question, > > > > there should be no need to introduce yet another property to adjust the > > > > keymap to reflect the reality. If a device uses "non classic" ChromeOS > > > > top row it should not be using the default keymap from > > > > arch/arm/boot/dts/cros-ec-keyboard.dtsi but supply its own. You can > > > > consider splitting the keymap into generic lower portion and the top row > > > > and moving them into an .h file so they can be easily reused. > > > > > > > > > > > > > > > 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. > > > > > > > > *for now* The mapping for the rest of the keyboard has also stayed > > > > static, but we still did not hardcode this information in the driver but > > > > rather used DT property to pass it into the kernel. > > > > > > > > > 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. > > Given the reason above, can we just add `num-top-row-keys` property > > instead of the whole `function-row-physmap`? > > I think this is the only thing cros_ec_keyb needs to know to generate > > the board-specific function-row-physmap file for the userspace. > > This would mean that we need to hard-code the knowledge of the scan > matrix in the driver and will not allow us to "skip" any keys in the top > row. Given that we did not hard-code the keymap I do not see why we > would want to do it differently with the top row. function-row-physmap > provides greatest flexibility and I do not see any downsides. OK. I updated in v2. PTAL. Thanks. > > Thanks. > > -- > Dmitry
diff --git a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml index 8e50c14a9d778..f105eae1cf445 100644 --- a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml +++ b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml @@ -31,6 +31,13 @@ properties: if the EC does not have its own logic or hardware for this. type: boolean + google,custom-keyb-top-row: + $ref: '/schemas/types.yaml#/definitions/uint16-array' + description: | + An ordered u16 array containing the action keycode values of the function + keys, from left to right. Specified only when the board has a custom + design for the top row keys on the keyboard. + required: - compatible
This patch adds a new property `google,custom-keyb-top-row` to the device tree for the custom keyboard top row design. Signed-off-by: Philip Chen <philipchen@chromium.org> --- .../devicetree/bindings/input/google,cros-ec-keyb.yaml | 7 +++++++ 1 file changed, 7 insertions(+)