My thought is that keyboards lend themselves naturally to an event-based model. You call each key an 'event' and define an action to be executed when that event happens. The actions come from a nice clean API of stuff the keyboard can do. An example:
OK, so this would be for the user defining key maps, macros, and so on?
I can see some inconsistencies in the example, but I suppose this is just an idea for how it could be written down, right? Maybe the forum on
http://geekey.org/ is a more appropriate place for discussing the details, though...
I gather our little microcontroller isn't going to have enough memory/power to process something like this on the fly, but it would be trivial to generate whatever format was needed from a description like this (including binary formats). Using this single representation, you could generate mappings for various controllers, or xmodmap files, or whatever else.
Basically, this is what I am doing in my own firmware already, but in a more limited way (e.g., no macros). There is a config file describing the keyboard (row/column-to-key assignments), and there are files that describe how to transform from the generic QWERTY map to anything else. A Python script takes these and produces a C structure that is used in the microcontroller program for processing the keystrokes.
At the moment, this key map structure is hardcoded into the firmware, but reading alternative key maps from EEPROM can be done easily. Maybe I can do that over the weekend...
So anyway, I have no idea if this is helpful or just redundant, since I haven't really seen how existing keyboard programming models work...
I haven't seen those either, but I guess you are supposed to use some GUI program for programming them. I wouldn't want that.
As for getting what I generate onto the board, someone suggested putting some kind of microSD reader or something on the controller. That sounds good to me. Create a config like above, generate microcontroller code, put on microSD card, hit a button on bottom of keyboard to make it read new settings... something like that.
Generating MCU code might not work since not all MCUs can execute code from RAM, but only from their flash memories. Therefore, the generated code would have to be some bytecode for a virtual machine to be interpreted by the MCU, so the MCU needs to run a virtual machine interpreter.
This is doable, provided the VM is kept simple.