| Marek Vasut | 15c6935 | 2012-08-08 01:42:17 +0000 | [diff] [blame] | 1 | The U-Boot Driver Model Project |
| 2 | =============================== |
| 3 | Keyboard input analysis |
| 4 | ======================= |
| 5 | Marek Vasut <marek.vasut@gmail.com> |
| 6 | 2012-02-20 |
| 7 | |
| 8 | I) Overview |
| 9 | ----------- |
| 10 | |
| 11 | The keyboard drivers are most often registered with STDIO subsystem. There are |
| 12 | components of the keyboard drivers though, which operate in severe ad-hoc |
| 13 | manner, often being related to interrupt-driven keypress reception. This |
| 14 | components will require the most sanitization of all parts of keyboard input |
| 15 | subsystem. |
| 16 | |
| 17 | Otherwise, the keyboard is no different from other standard input but with the |
| 18 | necessity to decode scancodes. These are decoded using tables provided by |
| 19 | keyboard drivers. These tables are often driver specific. |
| 20 | |
| 21 | II) Approach |
| 22 | ------------ |
| 23 | |
| 24 | The most problematic part is the interrupt driven keypress reception. For this, |
| 25 | the buffers that are currently shared throughout the whole U-Boot would need to |
| 26 | be converted into driver's private data. |
| 27 | |
| 28 | III) Analysis of in-tree drivers |
| 29 | -------------------------------- |
| 30 | |
| 31 | 1) board/mpl/common/kbd.c |
| 32 | ------------------------- |
| 33 | This driver is a classic STDIO driver, no problem with conversion is expected. |
| 34 | Only necessary change will be to move this driver to a proper location. |
| 35 | |
| 36 | 2) board/rbc823/kbd.c |
| 37 | --------------------- |
| 38 | This driver is a classic STDIO driver, no problem with conversion is expected. |
| 39 | Only necessary change will be to move this driver to a proper location. |
| 40 | |
| 41 | 3) drivers/input/keyboard.c |
| 42 | --------------------------- |
| 43 | This driver is special in many ways. Firstly because this is a universal stub |
| 44 | driver for converting scancodes from i8042 and the likes. Secondly because the |
| 45 | buffer is filled by various other ad-hoc implementations of keyboard input by |
| 46 | using this buffer as an extern. This will need to be fixed by allowing drivers |
| 47 | to pass certain routines to this driver via platform data. |