forked from thkala/actkbd
-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODO
80 lines (59 loc) · 3.43 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
1. Items in the ToDo list:
* Perform some testing on non-IA32 platforms, especially on 64-bit and
big-endian CPUs - some external feedback is welcome.
* Implement the module subsystem. Modules to control sound mixers e.t.c. could
be built.
UPDATE: The attribute infrastructure introduced in actkbd-0.2.0 is the core
of the module subsystem. Now we are just missing the modules...
* Support additional platforms. To do this, alternatives to linux.c must be
written and the build system must become smarter (autotools ?). I would
also need maintainers for any platform apart from Linux, since I do not
see myself installing another OS any time soon.
* Find out if there are any good reasons (security ?) to replace the call
to system().
* Add support for symbolic key names in the configuration file. Can we do
do this while still keeping the code relatively portable and without using
huge fixed keymaps ?
* Create manual pages: actkbd.1, actkbd.conf.5
* A scripted (Python?) GUI configuration tool - the configuration file syntax
has become so complicated that it is starting to resemble a full programming
language...
* Autotools ?
2. Completed
* Research and update the documentation with information on how to couple actkbd
with the hotplug subsystem, so that multiple keyboards can be supported. Any
takers ?
UPDATE: A sample udev file is now provided. Pretty simple, actually...
* Find out what happens if the keyboard device suddenly disappears - I have
to find a USB keyboard to test this. Make sure we handle this gracefully -
no a SIGSEGV is NOT graceful.
UPDATE: actkbd acts as it should. Users using hotplugged devices can just
ignore the error message when they remove the keyboard.
3. Features that will probably never be added:
* Check/Implement support for linux-2.4 kernels. I can't even remember whether
those had a proper event interface...
RATIONALE: If someone still uses a linux-2.4 kernel, well, here's one more
reason to upgrade :-). linux-2.4 will probably not run on my development
system anyway...
* Multiple keyboard support.
RATIONALE: After careful consideration, it was determined that using a single
daemon to handle multiple, possibly very different, keyboards is not a
very good idea. The one prominent category of people that regularly use
multiple keyboards, namely the laptop owners, will usually need totally
different configuration settings for each keyboard, as the external one
will have many more keys and might be missing others (the WLAN switch
comes to mind). It would be simpler and much more efficient to setup the
hotplug scripts to launch multiple actkbd instances, each with its own
configuration file.
UPDATE: There is now a sample udev rule file that can be adapted for multiple
keyboards.
* Use select() to handle multiple keyboards, instead of just the first one,
and get a USB keyboard to test it.
RATIONALE: Multiple keyboard support will not be added at all, so...
* Dynamically attach to new keyboards - the select() infrastrusture is a
prerequisite for this - can we do this without periodically reading the
/proc/bus/input/devices file ? Perhaps, with some help from hotplug...
RATIONALE: Multiple keyboard support will not be added at all, so...
* Per-keyboard configuration - this may never be implemented since it would
complicate the code. Perhaps a hotplug script could handle this better.
RATIONALE: Multiple keyboard support will not be added at all, so...