[U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes

[U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes

[Simon Glass]

Hi Olof,

On Sun, Jan 1, 2012 at 10:09 PM, Olof Johansson <olof@lixom.net> wrote:
> This adds a simple device tree binding for simple key matrix data and
> a helper to fill in the platform data.
>
> The implementation is in a shared file outside if drivers/input/keyboard
> since some drivers in drivers/input/misc might be making use of it
> as well.
>
> Changes since v2:
> ?* Removed reference to "legacy" format with a subnode per key
> ?* Changed to a packed format with one cell per key instead of 3.
> ?* Moved new OF helper to separate file
> ?* Misc fixups based on comments
>
> Changes since v1:
> ?* Removed samsung-style binding support
> ?* Added linux,fn-keymap and linux,fn-key optional properties
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
> ---
> ?.../devicetree/bindings/input/matrix-keymap.txt ? ?| ? 27 ++++++
> ?drivers/input/Kconfig ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?4 +
> ?drivers/input/Makefile ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?1 +
> ?drivers/input/keyboard/Kconfig ? ? ? ? ? ? ? ? ? ? | ? ?1 +
> ?drivers/input/of_keymap.c ? ? ? ? ? ? ? ? ? ? ? ? ?| ? 87 ++++++++++++++++++++
> ?include/linux/input/matrix_keypad.h ? ? ? ? ? ? ? ?| ? 19 ++++
> ?6 files changed, 139 insertions(+), 0 deletions(-)
> ?create mode 100644 Documentation/devicetree/bindings/input/matrix-keymap.txt
> ?create mode 100644 drivers/input/of_keymap.c
>
> diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.txt b/Documentation/devicetree/bindings/input/matrix-keymap.txt
> new file mode 100644
> index 0000000..1db8e12
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/matrix-keymap.txt
> @@ -0,0 +1,27 @@
> +A simple common binding for matrix-connected key boards. Currently targeted at
> +defining the keys in the scope of linux key codes since that is a stable and
> +standardized interface at this time.
> +
> +Required properties:
> +- compatible: "matrix-keyboard-controller"
> +- linux,keymap: an array of packed 1-cell entries containing the equivalent
> + ?of row, column and linux key-code. The 32-bit big endian cell is packed
> + ?as:
> + ? ? ? row << 24 | column << 16 | key-code

This looks much better than the Samsung binding and the original 3-cell one.

U-Boot Tegra (keyboard patch series) currently uses a 16x8 matrix, and
uses a single byte (the ASCII character) for a total of 128 bytes per
keymap. Since U-Boot does not have (or apparently want) the concept of
key codes or the added code and intermediate data this requires, the
binding presented here will not suit U-Boot so far.

These rows and columns embedded in the cell make it more of a pain to
write the fdt description. If you just set up the cells in (column,
row) order and set the matrix size (rows, columns) then you end up
with 128 entries on Tegra. If you use uint16 then this could be 256
bytes instead of 512. The binding you present for Tegra would be 109 *
4 = 436 bytes. However I take your point that Fn maps are much more
sparse, so overall this is likely to be similar (512 bytes for either
method once Fn mappings are taken into account).

But going back to U-Boot, it does not have the intermediate table that
you malloc and decant into, it does not understand key codes so
doesn't know what to do when Shift is pressed, doesn't understand
languages, etc. In order to use these Linux bindings in U-Boot we
would need to add new input layer, extra decode code and intermediate
tables. I can almost hear the NAKs already (bear in mind fdt only went
into U-Boot in the December release and people are more sensitive to
code size / performance there than in Linux). I did ask about this on
this list a few weeks ago but no response yet.

We could perhaps add an alternative direct ASCII binding like this
example (which would have to be in a separate node):

                /* Use a packed binding which doesn't include
row,column numbers in each cell */
                packed-binding;
                matrix-columns = <8>;
                matrix-rows = <16>;
                ascii-binding;  /* ASCII characters instead of keycodes */
		u-boot,keymap  = /size/ 8 <00  00  'w' 's' 'a' 'z' 00  DE
				    00  00  00  00  00  00  00  00
				    00  00  00  00  00  00  00  00
				    '5' '4' 'r' 'e' 'f' 'd' 'x' 00
				    '7' '6' 't' 'h' 'g' 'v' 'c' ' '
				    '9' '8' 'u' 'y' 'j' 'n' 'b' 5C
				    '-' '0' 'o' 'i' 'l' 'k' ',' 'm'
				    00  '=' ']' 0D  00  00  00  00
				    00  00  00  00  DF  DF  00  00
				    00  00  00  00  00  DC  00  DD
				    00  00  00  00  00  00  00  00
				    '[' 'p' 27  ';' '/' '.' 00  00
				    00  00  08  '3' '2' 1E  00  00
				    00  7F  00  00  00  1D  1F  1C
				    00  00  00  'q' 00  00  '1' 00
				    1B  '`' 00  09  00  00  00  00>;
		u-boot,keymap-DF = /size/ 8 <00  00  'W' 'S' 'A' 'Z' 00  00
				    00  00  00  00  00  00  00  00
				    00  00  00  00  00  00  00  00
...

The DC-DF codes codes denote Shift, Fn and Ctrl keys which would need
a separate keymap - although we could probably calculate the Ctrl one.

[U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes

[Olof Johansson]

Hi,

On Mon, Jan 02, 2012 at 10:39:04AM -0800, Simon Glass wrote:
> > diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.txt b/Documentation/devicetree/bindings/input/matrix-keymap.txt
> > new file mode 100644
> > index 0000000..1db8e12
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/matrix-keymap.txt
> > @@ -0,0 +1,27 @@
> > +A simple common binding for matrix-connected key boards. Currently targeted at
> > +defining the keys in the scope of linux key codes since that is a stable and
> > +standardized interface at this time.
> > +
> > +Required properties:
> > +- compatible: "matrix-keyboard-controller"
> > +- linux,keymap: an array of packed 1-cell entries containing the equivalent
> > + ?of row, column and linux key-code. The 32-bit big endian cell is packed
> > + ?as:
> > + ? ? ? row << 24 | column << 16 | key-code
> 
> This looks much better than the Samsung binding and the original 3-cell one.
> 
> U-Boot Tegra (keyboard patch series) currently uses a 16x8 matrix, and
> uses a single byte (the ASCII character) for a total of 128 bytes per
> keymap. Since U-Boot does not have (or apparently want) the concept of
> key codes or the added code and intermediate data this requires, the
> binding presented here will not suit U-Boot so far.
>
> These rows and columns embedded in the cell make it more of a pain to
> write the fdt description. If you just set up the cells in (column,
> row) order and set the matrix size (rows, columns) then you end up
> with 128 entries on Tegra. If you use uint16 then this could be 256
> bytes instead of 512. The binding you present for Tegra would be 109 *
> 4 = 436 bytes. However I take your point that Fn maps are much more
> sparse, so overall this is likely to be similar (512 bytes for either
> method once Fn mappings are taken into account).

Looking at the keymap you posted, you define 62 keys and 16 function
keys. So if that is all you care about on your particular keyboard,
that means that the layout with the 1-cell format is 248 bytes for the
base keymap, and 64 bytes for the fn-keymap. The benefit of using the
row/column/keycode format is that the table is only as large as the
number of keys you care about.

> But going back to U-Boot, it does not have the intermediate table that
> you malloc and decant into, it does not understand key codes so
> doesn't know what to do when Shift is pressed, doesn't understand
> languages, etc. In order to use these Linux bindings in U-Boot we
> would need to add new input layer, extra decode code and intermediate
> tables. I can almost hear the NAKs already (bear in mind fdt only went
> into U-Boot in the December release and people are more sensitive to
> code size / performance there than in Linux). I did ask about this on
> this list a few weeks ago but no response yet.
> 
> We could perhaps add an alternative direct ASCII binding like this
> example (which would have to be in a separate node):

You keep saying "direct ASCII", but your map contains non-ASCII
characters. ASCII provides no way at all to specify things such as shift,
or arrow keys, or other common new keys on keyboards. Instead you have had to
make up an ad-hoc custom map that contains your own special codes for these
keys.

For example, for arrow keys you seem to overload the FS/GS/RS/US. I'm not
saying we expect to need to use those ascii codes, but it does seem arbitrary
to just grab them for arrow keys. So in essence you have come up with your own
encoding of non-ASCII keys instead of reusing what is already available through
the linux keycodes.

Also, for example with return, does it encode as CR, LF or CR+LF? Etc.

Doing a binding in pseudo-ASCII is just asking for extra complications, in my
opinion. Over time that encoding is likely to swell to similar sizes anyway,
but still be incompatible.

>                 /* Use a packed binding which doesn't include
> row,column numbers in each cell */
>                 packed-binding;
>                 matrix-columns = <8>;
>                 matrix-rows = <16>;
>                 ascii-binding;  /* ASCII characters instead of keycodes */
> 		u-boot,keymap  = /size/ 8 <00  00  'w' 's' 'a' 'z' 00  DE
> 				    00  00  00  00  00  00  00  00
> 				    00  00  00  00  00  00  00  00
> 				    '5' '4' 'r' 'e' 'f' 'd' 'x' 00
> 				    '7' '6' 't' 'h' 'g' 'v' 'c' ' '
> 				    '9' '8' 'u' 'y' 'j' 'n' 'b' 5C
> 				    '-' '0' 'o' 'i' 'l' 'k' ',' 'm'
> 				    00  '=' ']' 0D  00  00  00  00
> 				    00  00  00  00  DF  DF  00  00
> 				    00  00  00  00  00  DC  00  DD
> 				    00  00  00  00  00  00  00  00
> 				    '[' 'p' 27  ';' '/' '.' 00  00
> 				    00  00  08  '3' '2' 1E  00  00
> 				    00  7F  00  00  00  1D  1F  1C
> 				    00  00  00  'q' 00  00  '1' 00
> 				    1B  '`' 00  09  00  00  00  00>;
> 		u-boot,keymap-DF = /size/ 8 <00  00  'W' 'S' 'A' 'Z' 00  00
> 				    00  00  00  00  00  00  00  00
> 				    00  00  00  00  00  00  00  00
> ...
> 
> The DC-DF codes codes denote Shift, Fn and Ctrl keys which would need
> a separate keymap - although we could probably calculate the Ctrl one.

I had included the row/column property in my binding for KEY_FN, but in
hindsight it's probably just enough to decode that through the regular key
layout, since there will be an entry for it there.

> From a point of view of efficiency, drivers can simply keep a pointer
> to the appropriate property and read out the codes based on
> (row,column) position.
>
> If we have something like this, then in order for the keyboard to work
> in U-Boot, vendors would need to create a completely separate ASCII
> mapping. Yes I agree this is a bit of a pain, but the above map is
> fairly easy to type in, and quite compact.

It doesn't make sense to come up with a fresh, brand new binding that
requires anyone adding a new device to it to do extra work to do two
redunant descriptions of the same device. We should be able to find common
ground.

The KEY_* codes that are interesting all seem to be in the range of
0-83. In the u-boot case, that means the base KEY*-to-ascii table would
be 83 bytes.

That means that the memory consumption for your case above would be
4*62+4*16=312 bytes for the base+fn table, and then 3*83 = 249 bytes
for the KEY*-to-ASCII tables for regular/shift/ctrl, for a total of
561 bytes. I'm sure there will be a few special cases in the code just
like you have now for arrow keys, etc, but they don't have to be in the
83-byte table.

Sure, that is somewhat more than your 4*128 byte tables, but it is also
a much more flexible binding that is less likely to hit limitations down
the road.

> Given the push-back on the U-Boot list from Linux people about my
> bindings, I would like to work out the U-Boot side in this thread if
> possible, since it seems to be dependent on what Linux does. But I
> hope what is created is efficient enough not to bloat U-Boot or
> require an new input layer to be added just to use fdt.

I think it's a great idea to use a common binding, since there will just be
wasted effort for vendors to have to create two maps and keep them in sync.


-Olof

[U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes

[Simon Glass]

Hi Olof,

On Tue, Jan 3, 2012 at 7:43 AM, Olof Johansson <olof@lixom.net> wrote:
> Hi,
>
> On Mon, Jan 02, 2012 at 10:39:04AM -0800, Simon Glass wrote:
>> > diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.txt b/Documentation/devicetree/bindings/input/matrix-keymap.txt
>> > new file mode 100644
>> > index 0000000..1db8e12
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/input/matrix-keymap.txt
>> > @@ -0,0 +1,27 @@
>> > +A simple common binding for matrix-connected key boards. Currently targeted at
>> > +defining the keys in the scope of linux key codes since that is a stable and
>> > +standardized interface at this time.
>> > +
>> > +Required properties:
>> > +- compatible: "matrix-keyboard-controller"
>> > +- linux,keymap: an array of packed 1-cell entries containing the equivalent
>> > + ?of row, column and linux key-code. The 32-bit big endian cell is packed
>> > + ?as:
>> > + ? ? ? row << 24 | column << 16 | key-code
>>
>> This looks much better than the Samsung binding and the original 3-cell one.
>>
>> U-Boot Tegra (keyboard patch series) currently uses a 16x8 matrix, and
>> uses a single byte (the ASCII character) for a total of 128 bytes per
>> keymap. Since U-Boot does not have (or apparently want) the concept of
>> key codes or the added code and intermediate data this requires, the
>> binding presented here will not suit U-Boot so far.
>>
>> These rows and columns embedded in the cell make it more of a pain to
>> write the fdt description. If you just set up the cells in (column,
>> row) order and set the matrix size (rows, columns) then you end up
>> with 128 entries on Tegra. If you use uint16 then this could be 256
>> bytes instead of 512. The binding you present for Tegra would be 109 *
>> 4 = 436 bytes. However I take your point that Fn maps are much more
>> sparse, so overall this is likely to be similar (512 bytes for either
>> method once Fn mappings are taken into account).
>
> Looking at the keymap you posted, you define 62 keys and 16 function
> keys. So if that is all you care about on your particular keyboard,
> that means that the layout with the 1-cell format is 248 bytes for the
> base keymap, and 64 bytes for the fn-keymap. The benefit of using the
> row/column/keycode format is that the table is only as large as the
> number of keys you care about.

Yes - my point is that the number of entries in the 1-byte binding
(with no row, column embedded) is unlikely to be more than the next
power of 2. So by avoiding including 2 or 3 unnecessary bytes we can
actually get a size reduction in most cases. It is also easier to
enter IMO. Can the Linux key codes fit in 8 bits?

>
>> But going back to U-Boot, it does not have the intermediate table that
>> you malloc and decant into, it does not understand key codes so
>> doesn't know what to do when Shift is pressed, doesn't understand
>> languages, etc. In order to use these Linux bindings in U-Boot we
>> would need to add new input layer, extra decode code and intermediate
>> tables. I can almost hear the NAKs already (bear in mind fdt only went
>> into U-Boot in the December release and people are more sensitive to
>> code size / performance there than in Linux). I did ask about this on
>> this list a few weeks ago but no response yet.
>>
>> We could perhaps add an alternative direct ASCII binding like this
>> example (which would have to be in a separate node):
>
> You keep saying "direct ASCII", but your map contains non-ASCII
> characters. ASCII provides no way at all to specify things such as shift,
> or arrow keys, or other common new keys on keyboards. Instead you have had to
> make up an ad-hoc custom map that contains your own special codes for these
> keys.
>
> For example, for arrow keys you seem to overload the FS/GS/RS/US. I'm not
> saying we expect to need to use those ascii codes, but it does seem arbitrary
> to just grab them for arrow keys. So in essence you have come up with your own
> encoding of non-ASCII keys instead of reusing what is already available through
> the linux keycodes.
>
> Also, for example with return, does it encode as CR, LF or CR+LF? Etc.
>
> Doing a binding in pseudo-ASCII is just asking for extra complications, in my
> opinion. Over time that encoding is likely to swell to similar sizes anyway,
> but still be incompatible.

Yes it would be better to use one binding, just so long as it is
efficient and doesn't introduce a lot of new complexity in U-Boot
which is useful only with fdt.

>
>> ? ? ? ? ? ? ? ? /* Use a packed binding which doesn't include
>> row,column numbers in each cell */
>> ? ? ? ? ? ? ? ? packed-binding;
>> ? ? ? ? ? ? ? ? matrix-columns = <8>;
>> ? ? ? ? ? ? ? ? matrix-rows = <16>;
>> ? ? ? ? ? ? ? ? ascii-binding; ?/* ASCII characters instead of keycodes */
>> ? ? ? ? ? ? ? u-boot,keymap ?= /size/ 8 <00 ?00 ?'w' 's' 'a' 'z' 00 ?DE
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00 ?00 ?00 ?00 ?00 ?00 ?00 ?00
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00 ?00 ?00 ?00 ?00 ?00 ?00 ?00
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? '5' '4' 'r' 'e' 'f' 'd' 'x' 00
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? '7' '6' 't' 'h' 'g' 'v' 'c' ' '
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? '9' '8' 'u' 'y' 'j' 'n' 'b' 5C
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? '-' '0' 'o' 'i' 'l' 'k' ',' 'm'
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00 ?'=' ']' 0D ?00 ?00 ?00 ?00
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00 ?00 ?00 ?00 ?DF ?DF ?00 ?00
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00 ?00 ?00 ?00 ?00 ?DC ?00 ?DD
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00 ?00 ?00 ?00 ?00 ?00 ?00 ?00
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? '[' 'p' 27 ?';' '/' '.' 00 ?00
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00 ?00 ?08 ?'3' '2' 1E ?00 ?00
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00 ?7F ?00 ?00 ?00 ?1D ?1F ?1C
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00 ?00 ?00 ?'q' 00 ?00 ?'1' 00
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1B ?'`' 00 ?09 ?00 ?00 ?00 ?00>;
>> ? ? ? ? ? ? ? u-boot,keymap-DF = /size/ 8 <00 ?00 ?'W' 'S' 'A' 'Z' 00 ?00
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00 ?00 ?00 ?00 ?00 ?00 ?00 ?00
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00 ?00 ?00 ?00 ?00 ?00 ?00 ?00
>> ...
>>
>> The DC-DF codes codes denote Shift, Fn and Ctrl keys which would need
>> a separate keymap - although we could probably calculate the Ctrl one.
>
> I had included the row/column property in my binding for KEY_FN, but in
> hindsight it's probably just enough to decode that through the regular key
> layout, since there will be an entry for it there.

OK - just need some signal as to what key codes are modifiers.

>
>> From a point of view of efficiency, drivers can simply keep a pointer
>> to the appropriate property and read out the codes based on
>> (row,column) position.
>>
>> If we have something like this, then in order for the keyboard to work
>> in U-Boot, vendors would need to create a completely separate ASCII
>> mapping. Yes I agree this is a bit of a pain, but the above map is
>> fairly easy to type in, and quite compact.
>
> It doesn't make sense to come up with a fresh, brand new binding that
> requires anyone adding a new device to it to do extra work to do two
> redunant descriptions of the same device. We should be able to find common
> ground.

Yes I hope so.

>
> The KEY_* codes that are interesting all seem to be in the range of
> 0-83. In the u-boot case, that means the base KEY*-to-ascii table would
> be 83 bytes.
>
> That means that the memory consumption for your case above would be
> 4*62+4*16=312 bytes for the base+fn table, and then 3*83 = 249 bytes
> for the KEY*-to-ASCII tables for regular/shift/ctrl, for a total of
> 561 bytes. I'm sure there will be a few special cases in the code just
> like you have now for arrow keys, etc, but they don't have to be in the
> 83-byte table.
>
> Sure, that is somewhat more than your 4*128 byte tables, but it is also
> a much more flexible binding that is less likely to hit limitations down
> the road.

Thanks for looking at this. We still have the need of the intermediate
table but since that is in BSS I don't think it is a problem.

>
>> Given the push-back on the U-Boot list from Linux people about my
>> bindings, I would like to work out the U-Boot side in this thread if
>> possible, since it seems to be dependent on what Linux does. But I
>> hope what is created is efficient enough not to bloat U-Boot or
>> require an new input layer to be added just to use fdt.
>
> I think it's a great idea to use a common binding, since there will just be
> wasted effort for vendors to have to create two maps and keep them in sync.

I will have a look at this approach and see what the impact is, and
reply on this thread.

Regards,
Simon

>
>
> -Olof

[U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes

[Russell King - ARM Linux]

On Tue, Jan 03, 2012 at 08:22:21AM -0800, Simon Glass wrote:
> Can the Linux key codes fit in 8 bits?

That depends on your point of view.

If you hack on X, then the answer is yes and you ignore the squeels of
your users when certain key presses get misinterpreted.  (The Psion LX
platform, otherwise known as the Netbook Pro, suffered with this problem.)

If you are a kernel hacker, the answer is no, because key codes currently
go all the way to 0x300.

[U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes

[Dmitry Torokhov]

On Tue, Jan 03, 2012 at 04:29:30PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 03, 2012 at 08:22:21AM -0800, Simon Glass wrote:
> > Can the Linux key codes fit in 8 bits?
> 
> That depends on your point of view.
> 
> If you hack on X, then the answer is yes and you ignore the squeels of
> your users when certain key presses get misinterpreted.  (The Psion LX
> platform, otherwise known as the Netbook Pro, suffered with this problem.)
> 
> If you are a kernel hacker, the answer is no, because key codes currently
> go all the way to 0x300.

For bootloader environment 0-255 range is probably sufficient though,
the upper keys are somewhat recent additions to the maps...

-- 
Dmitry

[U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes

[Olof Johansson]

On Tue, Jan 3, 2012 at 8:44 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Tue, Jan 03, 2012 at 04:29:30PM +0000, Russell King - ARM Linux wrote:
>> On Tue, Jan 03, 2012 at 08:22:21AM -0800, Simon Glass wrote:
>> > Can the Linux key codes fit in 8 bits?
>>
>> That depends on your point of view.
>>
>> If you hack on X, then the answer is yes and you ignore the squeels of
>> your users when certain key presses get misinterpreted. ?(The Psion LX
>> platform, otherwise known as the Netbook Pro, suffered with this problem.)
>>
>> If you are a kernel hacker, the answer is no, because key codes currently
>> go all the way to 0x300.
>
> For bootloader environment 0-255 range is probably sufficient though,
> the upper keys are somewhat recent additions to the maps...

To keep things in common it would be convenient to not cap the key
code at 8 bits for everybody though, since we're looking at reaching
agreement on a common solution between firmware and linux. And no
matter what the size of the word is there will be need for a
translation table.


-Olof

[U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes

[Russell King - ARM Linux]

On Tue, Jan 03, 2012 at 08:44:32AM -0800, Dmitry Torokhov wrote:
> On Tue, Jan 03, 2012 at 04:29:30PM +0000, Russell King - ARM Linux wrote:
> > On Tue, Jan 03, 2012 at 08:22:21AM -0800, Simon Glass wrote:
> > > Can the Linux key codes fit in 8 bits?
> > 
> > That depends on your point of view.
> > 
> > If you hack on X, then the answer is yes and you ignore the squeels of
> > your users when certain key presses get misinterpreted.  (The Psion LX
> > platform, otherwise known as the Netbook Pro, suffered with this problem.)
> > 
> > If you are a kernel hacker, the answer is no, because key codes currently
> > go all the way to 0x300.
> 
> For bootloader environment 0-255 range is probably sufficient though,
> the upper keys are somewhat recent additions to the maps...

I assume you deem 'recent' to mean 8 years ago - they've been there since
at least 2.6.9, which is where the problem I refer to above was first
noticed.

[U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes

[Dmitry Torokhov]

On Tue, Jan 03, 2012 at 05:06:15PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 03, 2012 at 08:44:32AM -0800, Dmitry Torokhov wrote:
> > On Tue, Jan 03, 2012 at 04:29:30PM +0000, Russell King - ARM Linux wrote:
> > > On Tue, Jan 03, 2012 at 08:22:21AM -0800, Simon Glass wrote:
> > > > Can the Linux key codes fit in 8 bits?
> > > 
> > > That depends on your point of view.
> > > 
> > > If you hack on X, then the answer is yes and you ignore the squeels of
> > > your users when certain key presses get misinterpreted.  (The Psion LX
> > > platform, otherwise known as the Netbook Pro, suffered with this problem.)
> > > 
> > > If you are a kernel hacker, the answer is no, because key codes currently
> > > go all the way to 0x300.
> > 
> > For bootloader environment 0-255 range is probably sufficient though,
> > the upper keys are somewhat recent additions to the maps...
> 
> I assume you deem 'recent' to mean 8 years ago - they've been there since
> at least 2.6.9, which is where the problem I refer to above was first
> noticed.

Well, what's 8 years ;) On a more serious note keys above 255 are really
the extended set - keys of remote controls, camera control, touchpad,
various aplication launchers, etc that are not very interesting for
bootloader. But, as Olof mentioned, the encoding must be sufficient for
Linux as well as bootloader, so limiting it is not a good idea.

-- 
Dmitry