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...
