| paul@49 | 1 | = Future Work = |
| paul@49 | 2 | |
| paul@49 | 3 | Some device servers could offer a broader range of operations and there could |
| paul@49 | 4 | be increased consistency between implementations for different computing |
| paul@49 | 5 | devices. For example, CPM servers only support operations necessary for LCD |
| paul@49 | 6 | peripheral configuration. |
| paul@49 | 7 | |
| paul@49 | 8 | Additional device servers could be provided for peripherals already supported |
| paul@49 | 9 | by libraries. For example, GPIO functionality is currently not exposed via a |
| paul@49 | 10 | server. (L4Re's Io server seeks to support GPIO functionality in such a |
| paul@49 | 11 | fashion.) |
| paul@49 | 12 | |
| paul@49 | 13 | Panel details are provided by libraries containing the structure definitions |
| paul@49 | 14 | required by the LCD device code. These libraries may eventually be replaced by |
| paul@49 | 15 | simple resource data files, but it is convenient to be able to use definitions |
| paul@49 | 16 | found in header files and to take advantage of structure definitions by just |
| paul@49 | 17 | encoding such details in source code and then turning such code into a |
| paul@49 | 18 | library. |
| paul@49 | 19 | |
| paul@49 | 20 | Framebuffer device servers are not currently used, since fb-drv effectively |
| paul@49 | 21 | offers the desired functionality together with other things. |
| paul@49 | 22 | |
| paul@49 | 23 | The input event device support needs to be made properly interoperable with |
| paul@49 | 24 | the L4Re event framework so that existing software can be supplied with keypad |
| paul@49 | 25 | events. |
| paul@49 | 26 | |
| paul@49 | 27 | Keypad device support should support interrupt handling to allow the scanning |
| paul@49 | 28 | activity to sleep when no activity is taking place. |
| paul@49 | 29 | |
| paul@49 | 30 | Plenty of other hardware support should be introduced. |
