Author Topic: "Open Source" Generic keyboard controller.  (Read 108122 times)

0 Members and 1 Guest are viewing this topic.

Offline talis

  • Thread Starter
  • Posts: 195
"Open Source" Generic keyboard controller.
« on: Fri, 25 September 2009, 14:28:49 »
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).

Offline lowpoly

  • Posts: 1749
"Open Source" Generic keyboard controller.
« Reply #1 on: Fri, 25 September 2009, 14:44:13 »
I'm interested.

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

Miniguru thread at GH // The Apple M0110 Today

Offline wellington1869

  • Posts: 2885
"Open Source" Generic keyboard controller.
« Reply #2 on: Fri, 25 September 2009, 15:18:00 »
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 ;)

"Blah blah blah grade school blah blah blah IBM PS/2s blah blah blah I like Model Ms." -- Kishy

using: ms 7000/Das 3

Offline msiegel

  • Posts: 1230
"Open Source" Generic keyboard controller.
« Reply #3 on: Fri, 25 September 2009, 15:28:41 »
i'm interested too :)

Filco Zero (Fukka) AEKII sliders and keycaps * Filco Tenkeyless MX brown * IBM F/AT parts: modding
Model F Mod Log * Open Source Generic keyboard controller

Offline talis

  • Thread Starter
  • Posts: 195
"Open Source" Generic keyboard controller.
« Reply #4 on: Fri, 25 September 2009, 16:27:56 »
Quote from: wellington1869;120553
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).

Offline msiegel

  • Posts: 1230
"Open Source" Generic keyboard controller.
« Reply #5 on: Fri, 25 September 2009, 16:35:51 »
Quote from: talis;120569
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 :D

Filco Zero (Fukka) AEKII sliders and keycaps * Filco Tenkeyless MX brown * IBM F/AT parts: modding
Model F Mod Log * Open Source Generic keyboard controller

Offline lowpoly

  • Posts: 1749
"Open Source" Generic keyboard controller.
« Reply #6 on: Fri, 25 September 2009, 16:57:00 »
What's the state of the Korean controller that has been announced some time ago?

Miniguru thread at GH // The Apple M0110 Today

Offline lowpoly

  • Posts: 1749
"Open Source" Generic keyboard controller.
« Reply #7 on: Fri, 25 September 2009, 16:58:56 »
Quote from: msiegel;120573
yes, a custom controller would enable many modding projects.

such as heavily modifying an ibm model f :D


Capacitive switches may require special electronics though.

Miniguru thread at GH // The Apple M0110 Today

Offline msiegel

  • Posts: 1230
"Open Source" Generic keyboard controller.
« Reply #8 on: Fri, 25 September 2009, 17:03:58 »
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 :(

Filco Zero (Fukka) AEKII sliders and keycaps * Filco Tenkeyless MX brown * IBM F/AT parts: modding
Model F Mod Log * Open Source Generic keyboard controller

Offline lowpoly

  • Posts: 1749
"Open Source" Generic keyboard controller.
« Reply #9 on: Fri, 25 September 2009, 17:17:08 »
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

Miniguru thread at GH // The Apple M0110 Today

Offline talis

  • Thread Starter
  • Posts: 195
"Open Source" Generic keyboard controller.
« Reply #10 on: Fri, 25 September 2009, 17:18:02 »
Quote from: lowpoly;120580
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).

Offline talis

  • Thread Starter
  • Posts: 195
"Open Source" Generic keyboard controller.
« Reply #11 on: Fri, 25 September 2009, 17:22:22 »
Quote from: lowpoly;120588
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 .

Offline dmw

  • Posts: 84
    • http://humblehacker.com
"Open Source" Generic keyboard controller.
« Reply #12 on: Fri, 25 September 2009, 17:26:48 »
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.

Offline rdh

  • Posts: 121
"Open Source" Generic keyboard controller.
« Reply #13 on: Fri, 25 September 2009, 18:17:24 »
Quote from: dmw;120593
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.
at home: IBM "Space Saving" Model M
at work: Topre Realforce 87UKB55


Offline lowpoly

  • Posts: 1749
"Open Source" Generic keyboard controller.
« Reply #14 on: Fri, 25 September 2009, 18:21:41 »
Quote from: dmw;120593
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?

Quote
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:

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

Quote from: rdh;120601
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
« Last Edit: Fri, 25 September 2009, 18:42:12 by lowpoly »

Miniguru thread at GH // The Apple M0110 Today

Offline rdh

  • Posts: 121
"Open Source" Generic keyboard controller.
« Reply #15 on: Fri, 25 September 2009, 19:07:01 »
Thanks, lowpoly!
at home: IBM "Space Saving" Model M
at work: Topre Realforce 87UKB55


Offline abio

  • Posts: 9
"Open Source" Generic keyboard controller.
« Reply #16 on: Sat, 26 September 2009, 13:51:50 »
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 ...

Offline wellington1869

  • Posts: 2885
"Open Source" Generic keyboard controller.
« Reply #17 on: Sat, 26 September 2009, 14:24:21 »
maybe a sourceforge page or a wiki is in order to start organizing needs and assets...

"Blah blah blah grade school blah blah blah IBM PS/2s blah blah blah I like Model Ms." -- Kishy

using: ms 7000/Das 3

Offline cfishy

  • Posts: 60
+1
« Reply #18 on: Sun, 27 September 2009, 20:30:33 »
I'll be happy to help.

Offline msiegel

  • Posts: 1230
"Open Source" Generic keyboard controller.
« Reply #19 on: Sun, 27 September 2009, 20:42:39 »
it sounds like one of the things this controller will need is a high performance debounce algorithm, that uses very little memory :)

Filco Zero (Fukka) AEKII sliders and keycaps * Filco Tenkeyless MX brown * IBM F/AT parts: modding
Model F Mod Log * Open Source Generic keyboard controller

Offline lowpoly

  • Posts: 1749
"Open Source" Generic keyboard controller.
« Reply #20 on: Mon, 28 September 2009, 05:25:44 »
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.
« Last Edit: Mon, 28 September 2009, 05:29:51 by lowpoly »

Miniguru thread at GH // The Apple M0110 Today

Offline abio

  • Posts: 9
"Open Source" Generic keyboard controller.
« Reply #21 on: Mon, 28 September 2009, 06:38:31 »
  • 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.

Offline talis

  • Thread Starter
  • Posts: 195
"Open Source" Generic keyboard controller.
« Reply #22 on: Mon, 28 September 2009, 10:29:24 »
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.
« Last Edit: Mon, 28 September 2009, 10:50:18 by talis »

Offline msiegel

  • Posts: 1230
"Open Source" Generic keyboard controller.
« Reply #23 on: Mon, 28 September 2009, 11:41:32 »
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 :)

Filco Zero (Fukka) AEKII sliders and keycaps * Filco Tenkeyless MX brown * IBM F/AT parts: modding
Model F Mod Log * Open Source Generic keyboard controller

Offline mech

  • Posts: 64
"Open Source" Generic keyboard controller.
« Reply #24 on: Mon, 28 September 2009, 13:52:24 »
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.

BS: IBM Model M 1391401 (1989) & Lexmark-made IBM Model M from 1991
Cherry MX Blue: Das Keyboard II/G80
Black ALPS: Dell AT101W (2)

Offline msiegel

  • Posts: 1230
"Open Source" Generic keyboard controller.
« Reply #25 on: Mon, 28 September 2009, 14:14:36 »
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.

Filco Zero (Fukka) AEKII sliders and keycaps * Filco Tenkeyless MX brown * IBM F/AT parts: modding
Model F Mod Log * Open Source Generic keyboard controller

Offline lowpoly

  • Posts: 1749
"Open Source" Generic keyboard controller.
« Reply #26 on: Mon, 28 September 2009, 14:24:16 »
Quote from: CX23882;121204
(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!

Miniguru thread at GH // The Apple M0110 Today

Offline Mnemonix

  • Posts: 163
"Open Source" Generic keyboard controller.
« Reply #27 on: Tue, 29 September 2009, 13:56:13 »
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:

Offline mech

  • Posts: 64
"Open Source" Generic keyboard controller.
« Reply #28 on: Tue, 29 September 2009, 14:14:28 »
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.

BS: IBM Model M 1391401 (1989) & Lexmark-made IBM Model M from 1991
Cherry MX Blue: Das Keyboard II/G80
Black ALPS: Dell AT101W (2)

Offline Shawn Stanford

  • Posts: 368
"Open Source" Generic keyboard controller.
« Reply #29 on: Tue, 29 September 2009, 15:06:43 »
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?
The Brat Prince of COBOL

Offline itlnstln

  • Posts: 7048
"Open Source" Generic keyboard controller.
« Reply #30 on: Tue, 29 September 2009, 15:25:12 »
I think it is choice A, the replacement.


Offline mech

  • Posts: 64
"Open Source" Generic keyboard controller.
« Reply #31 on: Tue, 29 September 2009, 15:37:02 »
In between would be good too, but I think the idea is to do lots of custom modding, up to and including bypassing crappy controllers.

Another upshot, the ATMEL chips are cheap.  Perhaps some good, free open source designs could be used by real manufacturers.  Then you'd know what you're getting if they say they support OpenKeyboard v. X (whatever X happens to be).  You also know you have a shot of getting it flashed if there's a problem that needs fixing, although I wouldn't expect a manufacturer to make that a user-serviceable operation.

BS: IBM Model M 1391401 (1989) & Lexmark-made IBM Model M from 1991
Cherry MX Blue: Das Keyboard II/G80
Black ALPS: Dell AT101W (2)

Offline msiegel

  • Posts: 1230
"Open Source" Generic keyboard controller.
« Reply #32 on: Tue, 29 September 2009, 17:31:34 »
welcome Mnemonix!

your project is very exciting :D

we will surely appreciate any experience or code you want to share

Filco Zero (Fukka) AEKII sliders and keycaps * Filco Tenkeyless MX brown * IBM F/AT parts: modding
Model F Mod Log * Open Source Generic keyboard controller

Offline Mnemonix

  • Posts: 163
"Open Source" Generic keyboard controller.
« Reply #33 on: Tue, 29 September 2009, 17:48:52 »
Quote from: mech;121481
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.


Thanks. Yes, the key map is, in principal, decoupled from the layout. By layout you mean the arrangement of switches on the physical keyboard matrix, and by map you mean the assignment of keys to switches--is that correct? In these terms, I am using a US QWERTY map as a reference to define which key is on which row/column on the layout. The codes in my config files are the standard USB keycodes.
Then, there are various key map transformations. To obtain, for instance, a Dvorak map, I am applying a transformation that tells how to swap keys on a US map in order to get Dvorak. The transformation is independent of the layout and can be reused for other layouts.

In the current version there is only a single map, and changing the map implies flashing the firmware. I'd like to change this and allow users to upload their own maps to EEPROM using some tool.

Quote from: mech;121481
How do you feel about listening for character sequences for switching to a certain map?


That's a very good idea. It would be a generalization of the Shift+ScrollLock combination that is used on the Space Saver for switching to numpad emulation. I should be well possible to implement this.

Quote from: mech;121481
US: QWERTY, Dvorak, Colemak, Dvorak (left handed), Dvorak (right handed), Dvorak variants?
Germany: QWERTZ, International Dvorak, Colemak?


Not sure if languages can be supported that way. When pressing, e.g., Shift+2 on a US keyboard, then the outcome is "@"; on a German keyboard it's """. On the USB protocol level, however, the keyboard simply sends the keycode for "2" plus the information that a shift key was held down, and it doesn't know that Shift+2 might be "@". Thus, the mapping of keys and modifiers is handled by the operating system.

On the other hand, there are certain country-specific USB keycodes that you could use in your map definitions (for instance, the key with "<>|" written on it, left from the Y key on German keyboards has its own code).

Quote from: mech;121481
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.)


That would be harder. Not impossible, but probably not as easily implemented as simply exchanging whole keyboard layouts.

Quote from: mech;121481
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.


OK, so you are imagining a set of commands that tell the keyboard what to do, a bit like command vs. edit mode in vim.
I really like the idea. :) The firmware takes only 3 kB of ROM space at the moment, 3.1 kB for the M4-1; that leaves about 11 kB on the ATMEGA16 for improvements... (2 kB are occupied by the boot loader)

Quote from: mech;121481
Ever use vi/vim?


Are there any other editors? ;)

Quote from: mech;121481
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.


Ah, that would be another vim-like mode. Or an extension of the key map management mode. I fear the AVR's EEPROM size will not be large enough for all this, though; there are only 512 bytes on the ATMEGA16, so the macros would be rather limited in their length. Some external non-volatile memory or a bigger AVR might come handy here.
And Emacs users might want to give vim a try. :D *SCNR*

Quote from: mech;121481
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.


What would that be useful for? Turning the keyboard into a chat bot? Moving a game character around in an automated fashion, but pretending it is controlled by a human? (Hm, that *might* be useful! :eyebrows:)
Sorry, I haven't been into gaming for years, so maybe I don't quite get it.

The whole macro thing sounds interesting. Is there something I have missed during the last few years? :)

Offline Mnemonix

  • Posts: 163
"Open Source" Generic keyboard controller.
« Reply #34 on: Tue, 29 September 2009, 18:08:55 »
Quote from: mech;121506
In between would be good too, but I think the idea is to do lots of custom modding, up to and including bypassing crappy controllers


Yes, in my case it's bypassing crappy PS/2 to USB converters on a crappy computer by replacing the whole PS/2 keyboard controller (which is not so crappy) by another one.
The converters I have tried so far to get my PS/2 keyboard working on one of my computers are either glitching all the time (key strokes missed or repeated), or don't work at all. And those that do work (glitchy so) need a USB hub in-between, probably because they are drawing too much current from the USB port...

I also think that the PS/2 port will disappear in the future, and I want to be prepared for that day. Buying a new keyboard is not an option. ;)

Offline cfishy

  • Posts: 60
"Open Source" Generic keyboard controller.
« Reply #35 on: Tue, 29 September 2009, 18:48:38 »
Before getting excited about programmability, I would like to remind everyone of this unfortunate case that we must avoid:

http://www.engadget.com/2009/08/04/apple-keyboard-gets-hacked-like-a-ripe-papaya-perp-caught-on-vi/

I don't have a lot of background in device programming, but I have been thinking about how to ensure the firmware doesn't get updated if somebody gains root on the computer it's hooked up to. I'm thinking, it needs some sort of hardware switch that switches it on to 'programming mode' and would not allow the use of keyboard until it's switched back to 'normal mode' again.

Because, if someone can get to the hardware, they can do a lot more real damage anyway.

We might also need a public key certification to ensure that the firmware people download from some site is not malicious.

The reason is two known problems:

1. unauthorized firmware update by compromised host computer.
2. I recall a wide spread problem with programmable Anykey boards where people forget to turn off programming mode and caused confusion. Some IT department to ban those keyboards altogether.

Offline msiegel

  • Posts: 1230
"Open Source" Generic keyboard controller.
« Reply #36 on: Tue, 29 September 2009, 19:12:26 »
a "program" switch, eh?

that sounds simple enough :)

Filco Zero (Fukka) AEKII sliders and keycaps * Filco Tenkeyless MX brown * IBM F/AT parts: modding
Model F Mod Log * Open Source Generic keyboard controller

Offline cfishy

  • Posts: 60
Bluetooth
« Reply #37 on: Tue, 29 September 2009, 20:38:36 »
My wish list is Bluetooth.

Bluetooth HID specification is simply a wrapper of the USB specification, so it shouldn't be hard to hook up a Bluetooth chip if I knew how... Anyone got a clue how to do that?

Bluetooth keyboards are simply not feasible for small scale marketing because it needs FCC approval. (Although some Bluetooth chipsets are approved, supposedly simplify the process.)  An example is Filco's wireless keyboard simply deemed not feasible for marketing in the U.S.

When you brew your own, you don't need FCC's approval stamp and that's a major plus for me.

Offline skriefal

  • Posts: 235
  • Location: Utah, USA
"Open Source" Generic keyboard controller.
« Reply #38 on: Tue, 29 September 2009, 21:33:40 »
Quote from: Mnemonix;121474
As a result, my firmware now runs on the same hardware as the one used by RUMP and Dulcimer when built for the M.


So it's possible that I could flash your firmware onto my "Rump" controller board?  If so then I'll definitely considering testing this new firmware.

Offline msiegel

  • Posts: 1230
"Open Source" Generic keyboard controller.
« Reply #39 on: Tue, 29 September 2009, 21:39:26 »
innuendo alert :lol:

Filco Zero (Fukka) AEKII sliders and keycaps * Filco Tenkeyless MX brown * IBM F/AT parts: modding
Model F Mod Log * Open Source Generic keyboard controller

Offline cfishy

  • Posts: 60
About N-key rollover
« Reply #40 on: Tue, 29 September 2009, 23:05:34 »
What's microcontroller to do with ghosting? I thought that's all done in the external circuitry.

By the way, I'm still reading about USB 3.0 specs... seems like it allows for bigger packet size, meaning possible N-key rollover for USB 3.0. But I'm not sure if that applies to HID.

Oh, I'm in the San Francisco Bay Area, too, perhaps we can have a keyboard geeks meetup event! show and tell.
« Last Edit: Tue, 29 September 2009, 23:09:53 by cfishy »

Offline talis

  • Thread Starter
  • Posts: 195
"Open Source" Generic keyboard controller.
« Reply #41 on: Tue, 29 September 2009, 23:36:43 »
Quote from: cfishy;121556
Before getting excited about programmability, I would like to remind everyone of this unfortunate case that we must avoid:

http://www.engadget.com/2009/08/04/apple-keyboard-gets-hacked-like-a-ripe-papaya-perp-caught-on-vi/

I don't have a lot of background in device programming, but I have been thinking about how to ensure the firmware doesn't get updated if somebody gains root on the computer it's hooked up to. I'm thinking, it needs some sort of hardware switch that switches it on to 'programming mode' and would not allow the use of keyboard until it's switched back to 'normal mode' again.

Because, if someone can get to the hardware, they can do a lot more real damage anyway.

We might also need a public key certification to ensure that the firmware people download from some site is not malicious.

The reason is two known problems:

1. unauthorized firmware update by compromised host computer.
2. I recall a wide spread problem with programmable Anykey boards where people forget to turn off programming mode and caused confusion. Some IT department to ban those keyboards altogether.


Easily handled by transferring firmware/layouts on a uSD card, as the card doesn't mount on the PC as a drive when in the keyboard, there's no way to directly affect the firmware.

Quote
My wish list is Bluetooth.

Bluetooth HID specification is simply a wrapper of the USB specification, so it shouldn't be hard to hook up a Bluetooth chip if I knew how... Anyone got a clue how to do that?

Bluetooth keyboards are simply not feasible for small scale marketing because it needs FCC approval. (Although some Bluetooth chipsets are approved, supposedly simplify the process.) An example is Filco's wireless keyboard simply deemed not feasible for marketing in the U.S.

When you brew your own, you don't need FCC's approval stamp and that's a major plus for me.

TI makes the CC2510 family of bluetooth controllers, the problem is, unless its a self contained module (with a fully integrated RF deck, antenna, etc) you still need FCC approval.  You can skirt around the FCC a little bit by not explicitly including Bluetooth functionality, rather making it easy for the (skilled) end user to hack it in later.

Offline Specter_57

  • Posts: 143
Some thoughts.....
« Reply #42 on: Wed, 30 September 2009, 00:02:22 »
Hello readers.....

As I have a couple-three of the IBM 122-key terminal 'M' type keyboards, I have thought of this sort of thing for some time now...and here on GH there are many threads that may/would be of use and informative in relation to this project idea.

And, no surprise...it would seem the hardware part of this thing would be rather simple to implement...but the microcontroller programming part is where the difficulty will come in.  Me...I'm still on the bottom end of the learning curve when it comes to these devices   :-(

......

I was looking at this device for a short time...but didn't like the overall cost involved in shipping, etc...although it likely would fulfill the requirements of the project as discussed here in this thread.

Take a look-see here:

Sprintek keyboard controller - SK 5100/5101

http://www.sprintek.com/products/SK5100.aspx

......

Another possibility, perhaps...is to use an 89c51/2/3 or 89s51/2/3 series microcontroller (32 I/O pins, 40 pin DIP) *with* an 89c2051/2/3 or the 89s2051/2/3 series microcontroller ( 15 I/O pins, 20 pin DIP) ;  by that I mean use two devices, serially connected...and share some functions between them ...these are standard PDIP devices, which would allow for easier breadboarding of the circuitry...and these devices are very inexpensive...a search at Avnet Express will show the 89c2051 at under one dollar US and the 89c51, in some versions under $3.00 US.

And other microcontrollers have been mentioned and are feasible.

......

And also...do not forget or overlook the Keyboard Babel projects.

See here:

http://www.kbdbabel.org/

......

anyway...enough mumbling for now.     :-)

Spec57

Offline Mnemonix

  • Posts: 163
"Open Source" Generic keyboard controller.
« Reply #43 on: Wed, 30 September 2009, 02:25:56 »
Quote from: msiegel;121542
welcome Mnemonix! we will surely appreciate any experience or code you want to share


Thanks. I'll share all the code soon, need to clean up and pull straight a few things first.

Quote from: cfishy;121556
Before getting excited about programmability, I would like to remind everyone of this unfortunate case that we must avoid:

http://www.engadget.com/2009/08/04/apple-keyboard-gets-hacked-like-a-ripe-papaya-perp-caught-on-vi/


Agreed. The keyboard should not listen to programming requests all the time. Programming must involve explicit user intervention, and normal operation must not be allowed in programming mode so that the user cannot leave on the programming mode by accident.
I have implemented this by requiring the user to hold down a certain key while plugging in the USB cable.

Signing the firmware is definitely a good idea since a bogus firmware might still contain malicious code.

Quote from: skriefal;121579
So it's possible that I could flash your firmware onto my "Rump" controller board?  If so then I'll definitely considering testing this new firmware.


Yes, this will work. For the RUMP platform, my Keyboard Upgrade is just an alternative firmware. You will also get the LEDs working then (just needs three more resistors).

Quote from: cfishy;121588
What's microcontroller to do with ghosting? I thought that's all done in the external circuitry.


I am referring to an effect described here. It can be circumvented by adding diodes to the keyboard matrix, but that's hard.
So, alternatively, the firmware needs to detect constellations where ghosting may have occurred, and ignore those; otherwise, e.g., hitting the keys A, S, and X simultaneously on a Model M would result in a Z being registered, too. If you have a keyboard that avoids ghost keys in hardware already, then there is, of course, no need for preventing them in software.

Quote from: Specter_57;121593
As I have a couple-three of the IBM 122-key terminal 'M' type keyboards, I have thought of this sort of thing for some time now...


Hm, not sure how hard it would be to open this kind of keyboard for getting to see the matrix, but could try to find out its layout? How many columns and rows are there, which keys are attached to them? Maybe Google knows...
Maybe it's just an enhanced version of the 16x8 matrix as used on the 1391401. Supporting the terminal keyboards would be trivial then.

Offline JBert

  • Posts: 764
"Open Source" Generic keyboard controller.
« Reply #44 on: Wed, 30 September 2009, 02:27:52 »
Quote from: Mnemonix;121474
The hardware is based on the Atmel AVR ATMEGA16 or ATMEGA32 microcontroller (most probably, some other AVRs would be possible, too).
So I guess you want to use the V-USB firmware platform to run things on?
What about Atmel's USB-supported chips? Do these cost more, do these have real hardware support for USB and could they work better?

I haven't figured out the differences. Just asking if you had more information by chance.

Quote from: cfishy;121556
I don't have a lot of background in device programming, but I have been thinking about how to ensure the firmware doesn't get updated if somebody gains root on the computer it's hooked up to. I'm thinking, it needs some sort of hardware switch that switches it on to 'programming mode' and would not allow the use of keyboard until it's switched back to 'normal mode' again.
This is probably the safest way. Most µC boot loaders already do this, for examples see the AIKON and Teensy boards.

Quote from: cfishy;121556
We might also need a public key certification to ensure that the firmware people download from some site is not malicious.
I don't know whether public key certificates are really needed. After all, always check everything you download from the Internet. Even drivers might be infected, so you have to make sure you trust the web page you got it from.
PKC is only good to add "GeekHack approved" stamps.

Quote from: cfishy;121588
What's microcontroller to do with ghosting? I thought that's all done in the external circuitry.
That's not entirely right: the key matrix causes ghosting due to a "short circuit". Adding diodes resolves it.

If you do have a key matrix without diodes, you probably want the controller to detect ghosting and stop it from happening by blocking those keys.

Quote from: cfishy;121588
By the way, I'm still reading about USB 3.0 specs... seems like it allows for bigger packet size, meaning possible N-key rollover for USB 3.0. But I'm not sure if that applies to HID.

Oh, I'm in the San Francisco Bay Area, too, perhaps we can have a keyboard geeks meetup event! show and tell.
USB HID already has arbitrary packet sizes because the device tells the USB host what kind of packets it sends.

It's mainly the legacy "boot mode" which states that keyboards should use a fixed packet size when in this mode. This allows a BIOS routine to talk to a keyboard without needing to parse the packet descriptor, it can just extract the key presses from the packet because the values are always at the same locations. When not in this mode (i.e. "normal mode"), it should be possible to send more keys.

Your keyboard drivers still need to support larger packets though.
On top of that, Microsoft once recommended that all keyboards should use the legacy protocol both in boot and in normal mode because there were some computers out there where the BIOS wouldn't issue the "switch protocol" command. Those BIOSen couldn't use a keyboard which sends an altered descriptor, hence the need to push everyone in using the legacy protocol at any time.

Keyboard makers still seem to follow this guideline as if it were a rule. I don't know whether things have changed since then, but this guideline may actually be outdated.
AFAIK, Linux and BSD keyboard drivers should support more than those 6 keys. If the Das got those 12 KRO, check if it uses the default drivers or a custom one.
IBM Model F XT + Soarer's USB Converter || Cherry G80-3000/Clears

The storage list:
IBM Model F AT || Cherry G80-3000/Blues || Compaq MX11800 (Cherry brown, bizarre layout) || IBM KB-8923 (model M-style RD) || G81-3010 Hxx || BTC 5100C || G81-3000 Sxx || Atari keyboard (?)


Currently ignored by: nobody?

Disclaimer: we don\'t help you save money on [strike]keyboards[/strike] hardware, rather we make you feel less bad about your expense.
[/SIZE]

Offline cfishy

  • Posts: 60
"Open Source" Generic keyboard controller.
« Reply #45 on: Wed, 30 September 2009, 03:51:22 »
JBert,

From what I gathered, one problem with V-USB is that it hasn't been successfully ported to Arduino dev env and the like, meaning it requires a programmer. It's also picky about clock speed. Otherwise, I think it would work just fine, and cheap.

Offline Mnemonix

  • Posts: 163
"Open Source" Generic keyboard controller.
« Reply #46 on: Wed, 30 September 2009, 04:30:08 »
Quote from: JBert;121606
So I guess you want to use the V-USB firmware platform to run things on?
What about Atmel's USB-supported chips? Do these cost more, do these have real hardware support for USB and could they work better?

I haven't figured out the differences. Just asking if you had more information by chance.


This is exactly what I am doing. V-USB is quite nice--GPL for non-commercial applications, easy to use, and a reasonable memory footprint.

I haven't checked out the USB-enabled chips either. I think they are all SMD, so they are a bit harder to work with than DIL-40 chips. I guess they are also more expensive, but it might still be worth taking a closer look at them. Getting rid of V-USB would also mean that the design could go commercial without paying licensing fees.

Quote from: cfishy;121614
From what I gathered, one problem with V-USB is that it hasn't been successfully ported to Arduino dev env and the like, meaning it requires a programmer. It's also picky about clock speed. Otherwise, I think it would work just fine, and cheap.


Don't know about Arduino, but I can tell that V-USB requires 12 MHz or more. I had no problems at 12 MHz so far, but the same setup that worked at 12 MHz failed when going to 16 MHz (just noise on the I/O ports)--after recompiling and reprogramming, of course. I didn't investigate this issue any further, though.

Offline lowpoly

  • Posts: 1749
"Open Source" Generic keyboard controller.
« Reply #47 on: Fri, 02 October 2009, 03:51:48 »
I think we need a subforum to organize this project.

We could then proceed to split this thread into several new ones. Like

  • Wishlist
  • µController Overview
  • Hardware: Draft
  • Hardware: Development
  • Software: Draft
  • Software: µController Code
  • Software: Host/SDK
  • Related Projects


We also need a team member with mod powers to be able to split/merge threads and maybe move posts.

Miniguru thread at GH // The Apple M0110 Today

Offline InSanCen

  • Posts: 565
"Open Source" Generic keyboard controller.
« Reply #48 on: Fri, 02 October 2009, 15:39:00 »
I have some electronics knowledge, limited programming ability (Unless we're gonna control this with a Z80!), but I am willing to contribute whatever I can.
Currently Using :- IBM M13 1996, Black :
Currently Own :- 1391406 1989 & 1990 : AT Model F 1985 : Boscom 122 (Black) : G80-3000 : G80-1800 (x2) : Wang 724 : G81-8000LPBGB (Card Reader, MY) : Unitek : AT102W : TVS Gold :
Project's :- 122 key 1389620 Wireless ESP32 :
'Pooter :- Xeon E5-2680v4 : Machinist MR9A : 2x16GB DDR4 : Radeon RX6600 : NVME & Spinning rust :

Offline talis

  • Thread Starter
  • Posts: 195
"Open Source" Generic keyboard controller.
« Reply #49 on: Sat, 03 October 2009, 01:05:22 »
Just need a name, and I can set up a site for the project.