On Wed, Dec 28, 2011 at 10:06 PM, Stephen Warren <swarren@xxxxxxxxxx> 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@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
