[PATCH v2 2/2] Input: tegra-kbc - add default chromeos map

[Olof Johansson]

On Wed, Dec 28, 2011 at 10:06 PM, Stephen Warren <swarren at nvidia.com> wrote:
> Olof Johansson wrote at Wednesday, December 28, 2011 12:33 AM:
>> On Tue, Dec 27, 2011 at 10:50 PM, Dmitry Torokhov
>> <dmitry.torokhov at gmail.com> wrote:
>> > On Tue, Dec 27, 2011 at 10:19:30PM -0800, Olof Johansson wrote:
>> >> This adds a simple way to specify the ChromeOS-specific keyboard map
>> >> instead of the "standard" map that is used on other Tegra devices such
>> >> as Harmony-with-keyboard and Seaboard.
>> >>
>> >> I expect the number of different keyboard layouts to be quite limited,
>> >> and not many should be added over time. So instead of encoding the layout
>> >> in the device tree, with all the can of worms that entails w.r.t. agreeing
>> >> on a suitable binding, just add a property to specify that this is the
>> >> map to be used, and include it in the driver.
>> >>
>> >> If, over time, the number of mappings increase, the binding can be
>> >> updated to include a custom map as a new property, without having to
>> >> worry about backwards compatibility on existing devices.
>> >>
>> >
>> > I'd rather we did not make shortcuts and did the proper DT binding.
>> > Samsung folks want the similar thing so making a generic DT keymap
>> > parser and using it in the driver would be the best way.
>>
>> Ok, fair point. I found the last posted version of the samsung driver
>> in my archives so I'll continue the discussion there (see separate
>> followup there).
>
> I agree here. Simon Glass has posted some patches to U-Boot to add the
> Tegra KBC driver including DT bindings. Can you please co-ordinate with
> him to ensure the bindings you're proposing for the kernel match those
> he's proposing for U-Boot; from memory, I don't think they are so far.
> Also, we need to work out the issue of the kernel needing just the base
> and function-modified keymap, but U-Boot needing a shift- and ctrl-
> modified keymap since there's no input layer handling shift/ctrl in
> U-Boot.

I answered this in the other email; since the modifier keymaps don't
actually describe hardware functionality but instead software
remappings, it should be done in u-boot, and the device tree binding
should be focused on describing the hardware.

> I'd prefer that the DT binding be encoded as:
>
> matrix -> keycode for base
> matrix -> keycode for function-modified
>
> With the binding for those two defined by either the Tegra KBC binding or
> a generic matrix KBC binding.
>
> keycode -> keycode for shift-modified
> keycode -> keycode for ctrl-modified
>
> With the binding for those two defined by some kind of generic modifier
> mapping binding, so it could feed into the input layer on Linux, although
> in U-Boot, the Tegra KBC driver would have to handle it itself, since
> there's nowhere else to handle it.

This is in my opinion unnecessarily complicated, and it's trying to
push too much upper-layer information down into the hardware
description. Keeping the binding to the bare minimum needed to
describe the actual hardware configuration is the natural common
ground not just between u-boot and linux, but also with other
operating systems and between different hardware vendors.


-Olof