"Open Source" Generic keyboard controller.

[talis]

I've been thinking about this for a while now, and figured it was worth gauging the community interest in developing an open source (open hardware / software) generic keyboard controller for custom/mod projects.

The idea won't necessarily be to make available for sale a complete mod kit (tho if someone is willing to take up this mantle, there's no reason it can't happen), rather to put together all the information for someone with some skill/knowledge to build it on their own.

Some of the main features I've been considering for this include:

* Ability to select between PS/2, USB, (other) communications protocols.
* Ability to program the matrix/layers without needing development tools/source modifications.
* Standardized matrix interface that would make it easy to interface with most current keyboards (through separate interface cards probably), or work into new custom designs.
* Simple / inexpensive to build at home using "cheap" development tools (eg no $400 ICDs to program the chips).
* Ability to small run produce the boards cheaply.
* Well documented, easily extensible, modifiable etc.

I'd like to get an idea both of who would be interested in helping with the initial development of a project like this, and who would make use of such project if it was available (easy to use, well documented etc).

[lowpoly]

I'm interested.

There's also dmw's development which is supposed to be open source as well.

[wellington1869]

I think this is a fantastic idea.  While I dont have any specific skills to contribute, I'll definitely contribute my enthusiasm and "can-do" attitude! ;-D  I'll send out "positive vibes" at you guys while i'm meditating. And I'll create voodoo dolls of your opponents and stick them with pins.
I can also do the 'vision thing' really well, if you guys need to brainstorm at some point in the process

[msiegel]

i'm interested too

[talis]

I think this is a fantastic idea.  While I dont have any specific skills to contribute, I'll definitely contribute my enthusiasm and "can-do" attitude! ;-D  I'll send out "positive vibes" at you guys while i'm meditating. And I'll create voodoo dolls of your opponents and stick them with pins.
I can also do the 'vision thing' really well, if you guys need to brainstorm at some point in the process

I think the only way a project like this will succeed is if it's strongly community driven (rather then driven by the whims of the core team).   By focusing only on the controller, it will allow for the building in of almost, if not all, wanted features (as opposed to a whole keyboard design that ultimately has to be a compromise between features).

[msiegel]

By focusing only on the controller, it will allow for the building in of almost, if not all, wanted features

yes, a custom controller would enable many modding projects.

such as heavily modifying an ibm model f

[lowpoly]

What's the state of the Korean controller that has been announced some time ago?

[lowpoly]

yes, a custom controller would enable many modding projects.

such as heavily modifying an ibm model f

Capacitive switches may require special electronics though.

[msiegel]

that's ok

also, here's the LIMKB keyboard controller:
http://otd.kr/bbs/board.php?bo_table=album&wr_id=11152

maybe google translate will help

[lowpoly]

Thanks. AIKON was the new name. Couldn't remember that. Here's another page in english:

http://www.otd.kr/bbs/board.php?bo_table=aikon_manual&wr_id=10

[talis]

Capacitive switches may require special electronics though.

Capacitive switches would need different matrix hardware.  The idea of designing a standardized interface however can still deal with it (with an additional amount of work).  The idea would be to abstract away the actual hardware interface.  For a standard switch board, you would just need a passive interface between the matrix and the controller (basically a daughter card, or set of flywires to the matrix interface), for a capacitive one, you'd need a bit smarter interface.  One that would be capable of reading the capacitive switch state, and translating it to the standard interface of the controller (while not needing to handle protocol stacks, keycode translations etc).

[talis]

Thanks. AIKON was the new name. Couldn't remember that. Here's another page in english:

http://www.otd.kr/bbs/board.php?bo_table=aikon_manual&wr_id=10

PI Engineering makes a similar one as well; http://www.xkeys.com/custom/xkmatrix.php .

[dmw]

As far as a keyboard controller is concerned, if anyone is interested in my work thus far, I'll post the code.  It's based on Atmel's AT90USB chip, which I've found pretty straightforward to learn to use.

[rdh]

Atmel's AT90USB chip

Is that the same chip used in the "Teensy++" development board?  (I think so, but I'm not quite sure.)

I've been carrying around vague notions of using a Teensy or Teensy++ as a hardware key remapper.  I would guess the chips they use should be a pretty good fit for a keyboard controller project.

[lowpoly]

As far as a keyboard controller is concerned, if anyone is interested in my work thus far, I'll post the code.  It's based on Atmel's AT90USB chip, which I've found pretty straightforward to learn to use.

I think it would be nice to have a first look. Do you use the AT90USBKey demonstration board?

Is that the same chip used in the "Teensy++" development board? (I think so, but I'm not quite sure.)

The AT90USBKey uses an AT90USB1287, the Teensy++ a AT90USB646, the Teensy a ATMEGA32U4.

Difference between AT90USB1287 and AT90USB646:

The AT90USB1286 and AT90USB646 have an USB interface for applications communicating with a USB host. The AT90USB1287 and AT90USB647 comply with the USB On-The-Go (OTG) standard for use as Dual Role Devices (DRD) in applications operating as either host or function device. The USB host capability is key to embedded devices needing to communicate without PC intervention.

The AT90USB1286 and AT90USB1287 have 128 KBytes of In-System Programmable (ISP) Flash, 8 KBytes of RAM and 4 KBytes of EEPROM. The AT90USB646 and AT90USB647 are identical but with half the memory size. All devices have an on-chip bootloader that allows ISP through the USB bus providing unrivalled flexibility from development phase to field update.

From here.

I've been carrying around vague notions of using a Teensy or Teensy++ as a hardware key remapper.

That was here:

http://netzhansa.blogspot.com/2009/04/how-to-convert-your-symbolics-keyboard.html

[rdh]

Thanks, lowpoly!

[abio]

I'm definitely interested in helping if I can.

I'm currently doing a PhD in microelectronics and I've got some experience with MCUs ...

[wellington1869]

maybe a sourceforge page or a wiki is in order to start organizing needs and assets...

[cfishy]

I'll be happy to help.

[msiegel]

it sounds like one of the things this controller will need is a high performance debounce algorithm, that uses very little memory

[lowpoly]

Next steps would be

• collect wishes/requirements
• evaluate available hardware/microcontrollers

I guess?

My first wishlist, unsorted: :-)

• commercial use possible (= find a license we all can live with)
• programming possible with external programmer software
• multi-platform sdk for this programming software so I can write my own proprietary programmer
• if software-less programming, layout should be downloadable from keyboard to pc
• at least two additional layers
• must support locking switches for layers (for ex. to switch between Qwerty and Colemak)
• firmware upgradeable, must not brick
• cheap hardware, if possible
• if ps/2 support it should use the usb cable with a passive usb->ps/2 adapter

The last one will probably be nasty.

[abio]

• commercial use possible (= find a license we all can live with)

There's nothing forbidden commercial use if its an open source license. Just have to include the source...

• programming possible with external programmer software

I suppose this is possible to do through a special USB interface.

• multi-platform sdk for this programming software so I can write my own proprietary programmer
• if software-less programming, layout should be downloadable from keyboard to pc

As long as the protocol is open, none of these are a problem. If there's enough demand, it will be done.

• must support locking switches for layers (for ex. to switch between Qwerty and Colemak)

Not a bad idea, profiles... Can be already achieved through a software layer though.

• firmware upgradeable, must not brick

Bricking is always a risk, can't avoid it. :P

• cheap hardware, if possible

Cheap hardware only comes through mass production

• if ps/2 support it should use the usb cable with a passive usb->ps/2 adapter

This isn't actually that difficult to do, may need some additional level-sensing circuitry to detect a PS/2 connection though.

[talis]

I think all of those are pretty achievable.

I envision a platform based around a uC family with a fair number of options.  For the most part, there is no reason for most people not to go gross overkill with the uC, with the ability to use a smaller (cheaper, less powerful) version in a commercial product with the associated cost savings.

The plan at this point is to include a sD/usD card reader, and allow a number of layouts to be stored at the same time, with the desired one loaded at boot time (or allow for a change with a programmable key sequence).  The files stored on the flash card would be plain text files, that can be edited in any text editor, without the need (tho not removing the possibility) for a dedicated PC side app.  This also makes it much easier to program/reprogram the keyboard in pure PS/2 environments (or on the fly).  For example, you could plug the keyboard into a PC in a computer lab, and swap layouts on the fly if you desire.

I'd like for the layout to be as dynamic as possible, with the ability to make any key on the keyboard either a locking or a non-locking modifier, with a fairly large number of allowable over-riding layers, as well as a small number of compound layers.

There's no reason not to consider doing this all through direct access either (with on board flash memory for example), but it will also require maintaining a PC side application for Windows/'nix/OSX at the minimum.  Again, in this case, being able to re-flash the base code over the same interface should be a mandatory requirement rather then a desired feature.  As well as the ability to program over both PS/2 and USB.

The uC will need a fairly basic bootloader, that will allow re-programing of the core code using the same flash card interface.  That way the end user wouldn't need any development tools to re-write the code, or upgrade (tho this feature is easily removed in a commercial version if desired).

The steps as I see them are basically :
- Gather basic requirements
- Choose a platform that seems to have the capability of meeting the majority of these requirements, while leaving a fair amount of room for flexibility.
- Develop the hardware platform.
- Develop the software platform.

One of the big requirements I'd like to stick to if possible is to use all open source/free development tools.  I'd like for the end user to be able to download the source, modify/compile, load and run without needing to spend a penny on development tools (programmer, compilers, etc).  There's a number of open source schematic capture and PCB layout tools as well, they definitely aren't as nice or as powerful as the closed source versions (orcad, altium etc) but again, they will allow anyone in the future to mess with / modify the project.

[msiegel]

re: using all open source/free development tools

this is a great idea

also, there's a neat feature in p.i. engineering's y-mouse ps/2 to usb adapter: you open a text editor, then press a special key combination... the y-mouse "types out" a menu, and you enter choices to change settings

[mech]

Nice idea.  You probably want to be looking into Arduino and its variant controller boards.  I would focus on replacement controllers rather than ground-up DIY keyboard projects, although you should keep an eye on making those at least possible.

Open source keyboard controller hardware/software
+ Supported keyboard
+ Controller bypass/adapter board/guide

Would be incredible.  We could override any controller issues (Das III, for example) but also remap keys.  Gamers would love it for macros.  You can probably get a card slot for real cheap and have multiple layouts in there.

Here's a fun idea: put an R+G+B LED on the controller board and have people put an RGB value in the layout files.  Then when they switch, adjust the multicolor LED to whatever that value is.  (Bonus: have it tween to the color.)  For example, I'll set QWERTY to green and Dvorak to blue.  I press scroll lock twice within 2 seconds to shift layouts.

I can contribute software advice but I'm a hardware novice.

[msiegel]

if there's going to be ample flash memory on the controller chip, it would be smart to have a self-calibration procedure for key debouncing.

i.e., trigger calibration mode, then press and release each key a few times to enable the chip to record maximum bounce times.

this will enable a robust debounce algorithm... and the possibility of using different kinds of switches on the same board.

[lowpoly]

(wouldn't it be cool if you could get counters from keyboards for number of key presses, as you can for backlight hours from the service menu of LCD monitors)

Statistics module!

[Mnemonix]

Hi all!

Wow, I just saw this thread, and it forced me to register on geekhack instantly. :madgrin: What you are discussing here is a bit like what I am currently working on in my spare time: a--guess what--generic open source keyboard controller! I haven't published anything yet, but maybe I should very soon...

The hardware is based on the Atmel AVR ATMEGA16 or ATMEGA32 microcontroller (most probably, some other AVRs would be possible, too). The whole project was inspired about two months ago by RUMP (http://mg8.org/rump/) and Dulcimer (http://www.schatenseite.de/index.php?id=307&L=2), two projects aiming to convert the IBM Model M to USB. Both projects are working quite well, but each has its own set of shortcomings, so I decided to hack my own.

I am simply calling it Keyboard Upgrade for now (not good at inventing clever names)...

The controller is probably not as generic as suggested in this thread. I didn't plan to have a single hardware layout usable in all keyboards, but one PCB per keyboard for use as a drop-in replacement. (One reason is that there is not a lot of space available in some keyboards, and attaching the flat cables to some generic PCB might be challenging in these.) As a result, my firmware now runs on the same hardware as the one used by RUMP and Dulcimer when built for the M. Also, I didn't want One Single Firmware Image to fit them all, but model-specific, lean firmwares built from a set of common source code files, plus some model-specific glue codes. This approach seems to work quite well for me so far.

Anyway. Here are the "standard features" I have implemented already that you would expect to find on any USB keyboard:

• Standard USB HID (using V-USB from Objective Development).
• LEDs are supported.
• Debouncing.
• Good ghost key prevention.

Additional features:

• Keyboard layouts are generated from config files, required code is generated from these.
• Layouts can be remapped when generating them, e.g., for killing the Windows keys or for turning the pesky Caps Lock into an additional Control key; or for remapping the standard layout to Dvorak; or a combination of these--all without intervention of operating systems.
• Flexible design that is not limited to Model M keyboards.
• Comes with a boot loader, firmware flashing cannot brick the device (bootloadHID, also from Objective Development).
• Built using open source development tools (gcc for AVR, Autoconf, Automake), tested on Linux. May also build on Windows with Cygwin; at least firmware flashing should not be a problem there.
• Open source, non-commercial.

The controller can be used with various IBM Model Ms already (those that share the same keyboard matrix with the 1391401, including my trusty Space Saver).
An incarnation for the IBM M4-1 is on the way (works on my breadboard already), but without trackpoint support for now; I hope to get that supported some day, too.
In theory, the IBM RT3200 (aka Space Saver II) is ready to be supported, too, since I have made a config file describing its keyboard matrix layout already.

I also plan to add support for alternative layouts. Currently, there is only one default layout stored in the firmware ROM (standard QWERTY, unless the firmware image was built using a different layout). In the future, multiple layouts may be uploaded to the keyboard using some tool (haven't thought about that one, however), and stored in the microcontroller's EEPROM. The layout can then be chosen using DIP switches or jumpers. The default layout in the firmware ROM will still be in its place in future versions, and can serve as a fall-back in case the user managed to upload some broken layouts.

So, what do you guys think? :decision:

[mech]

Sounds pretty awesome.  Any way you can decouple the key map from the key layout?  If you use standard codes to represent the layout, you could make generic map files that hopefully wouldn't require a recompile & firmware upload.

How do you feel about listening for character sequences for switching to a certain map?  Like if there are 9 map slots, and I hit Scroll Lock + Scroll Lock + Numpad1 all within 2 secs to switch to layout #1.  SL + SL + Numpad0 back to layout 0.  Although realistically, you're just going to need regional layout packs.

US: QWERTY, Dvorak, Colemak, Dvorak (left handed), Dvorak (right handed), Dvorak variants?
Germany: QWERTZ, International Dvorak, Colemak?

I once had an old programmable keyboard where you could reassign buttons with a certain key sequence.  Program + key + program + other key (or something like that) would flip them and permanently store the flip.  (Too bad that keyboard was domes, and it used volatile storage that would perish with the battery.)

Anyway.  Beyond certain sets of keymaps, you may be able to get clever with how you activate features.  If SL+SL rotates the layout, maybe SL+SL+left Ctrl swaps control and caps lock.  I'm just trying to think of doing this in ways that don't require firmware builds/flashes, although I guess dip switches would be fine.

Let's be realistic though.  Outside the geekhack community, the place this will be most well received is where macros are necessary.  Ever use vi/vim?  It would be awesome if I could easily program a "normal mode" for some of the development tools I have that would be portable between computers, because it's integrated into my keyboard!  Emacs users might like a sticky control key feature.

And, um, on the DL, MMO guys might like it if macro playback could have humanizing randomization added.  As in, realistic and non-constant (but random) delays between keys in the macro sequence.

Anyway, I think you've found a community of people who would be interested in that.  The Arduino boards I talked about above already use ATMEL controllers, so you're on a realistic path at least.

[Shawn Stanford]

Pardon my ignorance, but are we talking about an onboard controller that will augment/replace the current onboard controller, or are we talking about an inline controller that will sit between the keyboard plug and the host computer?