[U-Boot] unified keyboard queuing?

Hello,
I was looking at adding another keyboard driver.
So far there is USB keyboard and AT keyboard both with its own queuing code and different incomplete translation table.
For one, USB keyboard has some fake arrow key hack which is *not* included in the AT keyboard code afaict.
I managed to read a button state on my tablet and send KEY_ENTER which produces some weird character because I was supposed to send '\r' to stdin instead.
With 3 ~ 7 buttons it is obviously desirable that users can configure what the buttons send. Both because the number of buttons is limited and because the logical button to physical button mapping may be different on some devices. So far I only saw Vol+ and Vol- swapped, though.
I see a few options here
1) hard code the 3 keys commonly used on tablets to do something useful so that people can use Vol+/Vol-/power to browse a menu and select an item. Tablets that have Vol+ and Vol- swapped will just be slightly annoying
2) make this configurable with some sort of options in Kconfig (7 options total for all supported keys). This should result in compiled code the size of (1)
3) make some central keyboard translation so that USB keyboard, AT keyboard and any other keyboard can send same keycodes which are translated to characters sent to stdin the same way. Use keycodes in Kconfig options or possibly read a dtb which specifies the key layout for Linux. Will result in much larger code for small 7-key keyboard but will possibly make keyboards more predictable overall.
Thanks
Michal

Hi Michal,
On 9 January 2015 at 09:33, Michal Suchanek hramrach@gmail.com wrote:
Hello,
I was looking at adding another keyboard driver.
So far there is USB keyboard and AT keyboard both with its own queuing code and different incomplete translation table.
For one, USB keyboard has some fake arrow key hack which is *not* included in the AT keyboard code afaict.
I managed to read a button state on my tablet and send KEY_ENTER which produces some weird character because I was supposed to send '\r' to stdin instead.
With 3 ~ 7 buttons it is obviously desirable that users can configure what the buttons send. Both because the number of buttons is limited and because the logical button to physical button mapping may be different on some devices. So far I only saw Vol+ and Vol- swapped, though.
I see a few options here
- hard code the 3 keys commonly used on tablets to do something
useful so that people can use Vol+/Vol-/power to browse a menu and select an item. Tablets that have Vol+ and Vol- swapped will just be slightly annoying
- make this configurable with some sort of options in Kconfig (7
options total for all supported keys). This should result in compiled code the size of (1)
- make some central keyboard translation so that USB keyboard, AT
keyboard and any other keyboard can send same keycodes which are translated to characters sent to stdin the same way. Use keycodes in Kconfig options or possibly read a dtb which specifies the key layout for Linux. Will result in much larger code for small 7-key keyboard but will possibly make keyboards more predictable overall.
See input.c which aims to do this. I forgot to move i8042.c over to use that framework, but a few other drivers use it. Also see key_matrix.c which implements the device tree binding, making the keyboard scan codes configurable.
Regards, Simon
participants (2)
-
Michal Suchanek
-
Simon Glass