Re: [U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes
On Tue, Jan 03, 2012 at 08:44:32AM -0800, Dmitry Torokhov wrote: > On Tue, Jan 03, 2012 at 04:29:30PM +, 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes
On Tue, Jan 03, 2012 at 05:06:15PM +, 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 +, 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes
On Tue, Jan 03, 2012 at 04:29:30PM +, 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes
On Tue, Jan 3, 2012 at 8:44 AM, Dmitry Torokhov wrote: > On Tue, Jan 03, 2012 at 04:29:30PM +, 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes
Hi Olof, On Tue, Jan 3, 2012 at 7:43 AM, Olof Johansson 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 000..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
Re: [U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes
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 000..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 >
Re: [U-Boot] [PATCH v3] Input: keyboard - add device tree bindings for simple key matrixes
Hi Olof, On Sun, Jan 1, 2012 at 10:09 PM, Olof Johansson 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 > --- > .../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 000..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
