Keyboard device tree bindings, and modifier mapping representation

[Stephen Warren]

Simon Glass is attempting to define a device tree binding for the Tegra
KBC controller, for use in U-Boot. I raised some issues re: how to
represent modifier mappings. We'd like the ask for any insight from the
Linux input people regarding this.

Tegra's KBC is a matrix keyboard controller. The original binding that
Simon is attempting to upstream contains four tables:

kbc at 7000e200 {
    keycode-plain = [00  00  'w' 's' 'a' 'z' ... ];
    keycode-fn =    [00  00  00  00  00  00  ... ];
    keycode-shift = [00  00  'W' 'S' 'A' 'Z' ... ];
    keycode-ctrl =  [00  00  17  13  01  1a  ... ];
};

keycode-plain lists the keycode generated by each matrix position when
no modifier is held.

keycode-fn is the same thing, but when the "Fn" key is pressed. It seems
reasonable to represent this "Fn" feature directly in the device tree,
since in non-matrix keyboards, "Fn" is generally implemented in the
keyboard hardware and invisible to software.

My main question is about keycode-shift and keycode-ctrl, which deal
with modifiers.

My assertion is that those aren't really hardware features; most
keyboard emit explicit keycodes for modifiers, and these are handled
purely in software at a higher level than the keyboard driver. Hence,
shift/ctrl shouldn't be represented in the same way as the plain/fn tables.

I believe the definition of keycode-shift/ctrl should be written such
that those properties could be re-used across any keyboard, rather than
being something custom for the Tegra KBC binding.

I imagine that if keycode-shift/ctrl were present in the device tree,
the kernel would simply ignore them and just use its standard keyboard
mapping mechanisms. Could keycode-shift/ctrl be used to initialize the
default mapping in the Linux kernel? I guess that would only affect the
console and not X, and it might be confusing to not use all the existing
mapping mechanisms.

In the binding above, the four tables both use the matrix position as
input, and give a keycode as output. I think that keycode-shift/ctrl
should take keycodes (from the plain/fn table output) and map them to
other keycodes. This would be more in line with typical keyboards, where
the modifier mapping operates at that level.

Note that U-Boot (where this binding is headed first) has no separate
input layer above the keyboard driver, and hence no generic shift/ctrl
modifier handling. At least initially, the Tegra KBC driver would have
to implement all 4 of those tables, irrespective of how the tables are
represented (as above, or as a generic keycode->keycode mapping table).
However, I'd like to come up with a binding now that's workable for both
U-Boot and the Linux kernel, and indeed any other SW.

What's the thinking of the linux-input maintainers here?

Thanks for reading.

-- 
nvpublic