Re: [PATCH] Input: keyboard - add device tree bindings for simple key matrixes

On 12/29/2011 01:06 AM, Olof Johansson wrote:

On Wed, Dec 28, 2011 at 11:01 PM, Stephen Warren [off-list ref] wrote:

quoted

Olof Johansson wrote at Wednesday, December 28, 2011 11:34 PM:

quoted

On Wed, Dec 28, 2011 at 10:16 PM, Stephen Warren [off-list ref] wrote:

quoted

Olof Johansson wrote at Wednesday, December 28, 2011 3:53 PM:

quoted

From: Dmitry Torokhov <redacted>

This adds a basic device tree binding for simple key matrix data.

Signed-off-by: Olof Johansson <redacted>
---

Based on email exchange this morning, this is a first cut at a shared
definition and helper function to parse and fill in the keymap data.

Instead of doing the direct parsing into the final keymap format, I
chose to fill in the pdata-equivalent since that is how the OF pdata
fillers work right now if code is to be kept common with the legacy
platform_device probe interface.

This is a prerequisite for a revised version of the tegra-kbc device
tree support that I will repost separately once this interface is stable.

...

quoted

diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.txt

...

quoted

+For simple keyboards with just a few buttons, you can specify each key
+as a subnode of the keyboard controller, with the following
+properties:
+
+- keypad,row: the row number to which the key is connected.
+- keypad,column: the column number to which the key is connected.
+- linux,code: the key-code to be reported when the key is pressed
+  and released.
+
+Example:
+
+     key_1 {
+             keypad,row = <0>;
+             keypad,column = <3>;
+             linux,code = <2>;
+     };
+
+
+For a more complex keyboard, such as a full laptop, a more compact
+binding can be used instead, with the following property directly in
+the keyboard controller node:
+
+- linux,keymap: an array of 3-cell entries containing the equivalent
+  of the three separate properties above: row, column and linux
+  key-code.

Why allow two completely different bindings? Is there some deficiency
to the compact binding that means it isn't suitable for all cases?

The main reason is that the samsung keyboard driver already implements
the more verbose one, and allowing that binding to coexist while also
providing a more compact one seems like the right thing to do.

Can we deprecate the Samsung format, and only allow it for that Samsung
device (and allow both there), and require a single format for any other
keyboard?

I'm definitely ok with that. Thomas, Grant, Rob? The code in question
is queued for 3.3, so it hasn't been out in a real release yet.

Adding Kukjin as well since it's getting merged through his tree.

I think both can coexist because the Samsung version is really a
derivative of gpio-keys binding. I think we want to encourage your
keymap version, so only supporting it in the generic code should do that.

Rob