|
| 1 | +1. Items in the ToDo list: |
| 2 | + |
1 | 3 | * Find out what happens if the keyboard device suddenly disappears - I have
|
2 | 4 | to find a USB keyboard to test this. Make sure we handle this gracefully -
|
3 | 5 | no a SIGSEGV is NOT graceful.
|
4 | 6 |
|
5 | 7 | * Perform some testing on non-IA32 platforms, especially on 64-bit and
|
6 | 8 | big-endian CPUs - some external feedback is welcome.
|
7 | 9 |
|
8 |
| -* Check/Implement support for linux-2.4 kernels. I can't even remember whether |
9 |
| - those had a proper event interface... |
10 |
| - |
11 | 10 | * Implement the module subsystem. Modules to control sound mixers e.t.c. could
|
12 | 11 | be built.
|
13 | 12 | UPDATE: The attribute infrastructure introduced in actkbd-0.2.0 is the core
|
14 | 13 | of the module subsystem. Now we are just missing the modules...
|
15 | 14 |
|
16 |
| -* Use select() to handle multiple keyboards, instead of just the first one, |
17 |
| - and get a USB keyboard to test it. |
18 |
| - |
19 |
| -* Dynamically attach to new keyboards - the select() infrastrusture is a |
20 |
| - prerequisite for this - can we do this without periodically reading the |
21 |
| - /proc/bus/input/devices file ? Perhaps, with some help from hotplug... |
22 |
| - |
23 |
| -* Per-keyboard configuration - this may never be implemented since it would |
24 |
| - complicate the code. Perhaps a hotplug script could handle this better. |
25 |
| - |
26 | 15 | * Support additional platforms. To do this, alternatives to linux.c must be
|
27 | 16 | written and the build system must become smarter (autotools ?). I would
|
28 | 17 | also need maintainers for any platform apart from Linux, since I do not
|
|
42 | 31 | language...
|
43 | 32 |
|
44 | 33 | * Autotools ?
|
| 34 | + |
| 35 | +* Research and update the documentation with information on how to couple actkbd |
| 36 | + with the hotplug subsystem, so that multiple keyboards can be supported. Any |
| 37 | + takers ? |
| 38 | + |
| 39 | + |
| 40 | + |
| 41 | +2. Features that will probably never be added: |
| 42 | + |
| 43 | +* Check/Implement support for linux-2.4 kernels. I can't even remember whether |
| 44 | + those had a proper event interface... |
| 45 | + RATIONALE: If someone still uses a linux-2.4 kernel, well, here's one more |
| 46 | + reason to upgrade :-). linux-2.4 will probably not run on my development |
| 47 | + system anyway... |
| 48 | + |
| 49 | +* Multiple keyboard support. |
| 50 | + RATIONALE: After careful consideration, it was determined that using a single |
| 51 | + daemon to handle multiple, possibly very different, keyboards is not a |
| 52 | + very good idea. The one prominent category of people that regularly use |
| 53 | + multiple keyboards, namely the laptop owners, will usually need totally |
| 54 | + different configuration settings for each keyboard, as the external one |
| 55 | + will have many more keys and might be missing others (the WLAN switch |
| 56 | + comes to mind). It would be simpler and much more efficient to setup the |
| 57 | + hotplug scripts to launch multiple actkbd instances, each with its own |
| 58 | + configuration file. |
| 59 | + |
| 60 | +* Use select() to handle multiple keyboards, instead of just the first one, |
| 61 | + and get a USB keyboard to test it. |
| 62 | + RATIONALE: Multiple keyboard support will not be added at all, so... |
| 63 | + |
| 64 | +* Dynamically attach to new keyboards - the select() infrastrusture is a |
| 65 | + prerequisite for this - can we do this without periodically reading the |
| 66 | + /proc/bus/input/devices file ? Perhaps, with some help from hotplug... |
| 67 | + RATIONALE: Multiple keyboard support will not be added at all, so... |
| 68 | + |
| 69 | +* Per-keyboard configuration - this may never be implemented since it would |
| 70 | + complicate the code. Perhaps a hotplug script could handle this better. |
| 71 | + RATIONALE: Multiple keyboard support will not be added at all, so... |
0 commit comments