From mboxrd@z Thu Jan 1 00:00:00 1970 From: Date: Mon, 05 Dec 2011 12:53:56 -0000 Subject: No subject Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de - drivers/input/keyboard.c has a translation table - drivers/input/i8042.c has a translation table also, and supports German and English - this driver which has a translation table in the fdt, which seems like a step forward We can certainly have a discussion about shift key translation and how it should work. The same discussion probably applies to un-shifted keys though, since they may well be printed differently in other languages. At least with the scheme in this series you can support any keyboard you like and have complete control over how it behaves. I think asking for a new input layer in U-Boot. But this does not exist at present. Don't you think this is taking things a little far? I am trying to upstream a hardware driver :-) My reading of the Tegra keyboard driver in the kernel is that it *could* use the keycode-plain and keycode-fn properties as given in this series. They would replace the tegra_kbc_default_keymap[] array. However, code would need to be added to create that array for use by the upper layers of linux keyboard input, since presumably it will be a while before the kernel's drivers/input/keyboard/matrix_keypad.c supports an fdt-based mapping. It certainly will not use a shift or ctrl mapping, since these are handled by upper layers of Linux input. So after all this musing I see two options: 1. Modify this series to remove 'shift' support and make 'ctrl' use a calculated value (i.e. unlike the other two existing U-Boot drivers). We lose access to a number of symbols but I could hard-code a mapping in for the keyboard on Seaboard, say. 2. a. Go with what we have, put a 'u-boot,' prefix on the keycode-shift property and don't expect the kernel to ever use it. b. Start talking on the U-Boot list about the need for a middle input translation layer and a generic header file which defines key codes in a standardized way. Then write this layer, get it accepted and refactor the 3 keyboard drivers to use it. Thoughts? Regards, Simon > > -- > nvpublic