Anyone interested in collaborating on a Kinesis controller upgrade kit?

[ryanc]

Hey all,

I've had this idea bouncing around in my head for a while to produce a Kinesis controller upgrade kit based on the Teensy. There has been some work done on this already here (I have one built, and basic firmware already exists):

http://michael.stapelberg.de/Artikel/kinesis_custom_controller

but I would like to take things a little further.

My desired feature set:

* RGB indicator LEDs (Ti TLC5940 based)

* Keyclick piezo speaker

* Foot pedal support

* Mouse emulation support

* Trackpoint mod support (including support for the proprietary trackpoint PS/2 extensions - I have the datasheet for that)

* Trackball support

* Ergodox style layered keymap support

From the above all but the RGB leds and possibly piezo speaker can be done with the hardware I already have, and I can code decently for microcontrollers already as well. Is this something that anyone else wants?

Would also be nice if it could be designed to support physically splitting the Kinesis.

I want the controller to handle the trackpoint or trackball so that the keyboard can modify the movement or possibly also change the behavior of certain keys when there has recently been movement.

edit So, people appear to have a bunch of desired pet features. Supporting all of them is probably a pain in the ass. If the GPIO used for actually reading the matrix can be minimized, we can have a few GPIO ports to support add-on boards which can be built later and be used with just a software update.

edit2 Looks like the TMK firmware would be a good starting point.

[Input Nirvana]

YES

I'll make a point of making certain that others I had rallied over the years see this.

[uberben]

I've been casually working on something similar on and off for a while. I had most of the same feature goals, plus bluetooth support. I've been working with Hasu's TMK firmware as a base and am currently adding support for the bluetooth modules' latest firmware. I would probably be interested in working together on something as time permits.

[ryanc]

Maybe have support for a daughterboard that can do the bluetooth and possibly also battery? Will have to do some GPIO budgeting.

[uberben]

Yeah, the way I was looking at it, I would use an I2C IO expander for half the keyboard, which would give the added benefit of allowing the keyboard to be split in the same way they split the ErgoDox. My plan was to make the BT and battery portions optional, just an non-populated parts.

[vvp]

I want to do this too. My main goal is to get rid of the original kinesis firmware. I think any other open firmware will be better but I consider especially chrisandreae's firmware because of the on the fly remap support. The second goal is a support for 8 keys per thumb cluster (I want to modify thumb clusters too).

But first I need to finish at least the first working Katy keyboard prototype so that I have something to use till my kinesis is being modified.

Will your new controller support 8 keys per thumb cluster?

[ryanc]

Will your new controller support 8 keys per thumb cluster?

That's a thing that would be lower priority, however there are two "dead" spots in the thumb matrices and if you hooked keys in there it'd be easy to support them by updating the code to recognize those matrix locations.

[ryanc]

Yeah, the way I was looking at it, I would use an I2C IO expander for half the keyboard, which would give the added benefit of allowing the keyboard to be split in the same way they split the ErgoDox. My plan was to make the BT and battery portions optional, just an non-populated parts.

Perhaps https://www.sparkfun.com/products/11378? Only requires six wires to hook up. I want to focus on USB first though.

[vvp]

That's a thing that would be lower priority, however there are two "dead" spots in the thumb matrices and if you hooked keys in there it'd be easy to support them by updating the code to recognize those matrix locations.

The two dead spots in the matrix of a thumb cluster cannot be used both with the original wiring of kinesis controller since left and right thumb cluster share some rows. I looked at your PCB and if I did not miss something this will not be a problem in your case since you do not seem to share any rows between thumb clusters. Well if you do not have there some sharing through the right rubber key block.

[uberben]

Perhaps https://www.sparkfun.com/products/11378? Only requires six wires to hook up. I want to focus on USB first though.

I'm currently using a Bluegiga WT12 module, and my plan was to design a pcb with a footprint for the bare module. It is a UART module, so just needs a couple IO. It also is pretty straight forward to use as a keyboard/mouse/gamepad/etc. and is similar in price. TMK also has partial support for it already, it just needs to be updated for the latest version. It looks like the RN-42 might only be able to do one profile at a time, which may or may not be an issue with combo keyboard and mouse.

If I'm not the only one that wants bluetooth, and everyone else wants to try the RN-42, I would be willing to try it.

[uberben]

The two dead spots in the matrix of a thumb cluster cannot be used both with the original wiring of kinesis controller since left and right thumb cluster share some rows. I looked at your PCB and if I did not miss something this will not be a problem in your case since you do not seem to share any rows between thumb clusters. Well if you do not have there some sharing through the right rubber key block.

With a fully custom main board, it doesn't really matter which lines are shared between all the key clusters. A while ago I mapped out the key matrices for each cluster and did some work to condense it into a relatively compact parent matrix. http://wiki.skullspace.ca/Custom_bluetooth_keyboard#Key_Matrix

I think we could easily squeeze in a couple buttons on each thumb cluster, but as ryanc mentioned, I don't think that would be a priority for most people. I have some palm keys in my main Kinesis that would be very tidy to plug into the thumb clusters, but we'll see what we end up with. Similarly, I want to replace the rubber switches on my board with 14 cherrys, but I don't expect many other people to want to inflict the same amount of damage to their cases.

What I was thinking of doing was breaking out all of the matrix IO lines into a few headers so that it would be easy for any user of the board to hook up whatever buttons they wanted to into the existing matrix, either in empty spots or even in parallel with other switches.

[vvp]

Ok, if adjusting the kinesis original matrix (e.g. for adding thumb cluster keys) is not a priority then there may be an easier and probably also cheaper way to do this. Do not try to use teensy and replace the whole controller board. Replace only the DIL40 controller with a double sided PCB and ATmega32u4 directly on it (as chrisandreae proposed it). It looks like it would fit. This way, it will work for both the new and the old type of connection between keywells and the main board. You would cover more potential users.

Something like this:


Edit: Or if the whole controller PCB is replaced then it may be designed so that it support both old and new keywells.

[vvp]

With a fully custom main board, it doesn't really matter which lines are shared between all the key clusters. A while ago I mapped out the key matrices for each cluster and did some work to condense it into a relatively compact parent matrix. http://wiki.skullspace.ca/Custom_bluetooth_keyboard#Key_Matrix

I looked at your condensed matrix today to check if there is a space for more keys in thumb clusters and I realized that you probably plan to rewire the switches on the thumb cluster PCBs.

Because notice that kinesis has the right thumb cluster switches 5 (RAlt), 2 (PgUp), and 1 (PgDn) at the same row (pin 7) of its thumb cluster PCB. But you do not have these switches on the same row or the same column in the condensed matrix.

That means that you either want to change the thumb cluster PCBs too or you have an error in the condensed matrix.

[uberben]

I looked at your condensed matrix today to check if there is a space for more keys in thumb clusters and I realized that you probably plan to rewire the switches on the thumb cluster PCBs.

Because notice that kinesis has the right thumb cluster switches 5 (RAlt), 2 (PgUp), and 1 (PgDn) at the same row (pin 7) of its thumb cluster PCB. But you do not have these switches on the same row or the same column in the condensed matrix.

That means that you either want to change the thumb cluster PCBs too or you have an error in the condensed matrix.

You are correct, there is an error in my diagram. I have swapped my Ctrl and Alt keys, so I placed those according to my keycaps, not the stock locations. I will correct the matrix according to the factory layout.

[vvp]

Ok, one option would be to also add Row pin5 signal to thumb cluster connectors. It is an input pin so it can be connected e.g. to  9 on thumb clusters. That is thumb cluster PCB plate (now probably set to ground). It would allow 9 thumb cluster buttons at the expense of not connecting the plate as it was. Not sure how serious it is (if it is a problem at all).
Well, this makes sense to me if it supports the old keywells too. Otherwise it is not usable to me anyway.

Another thing I do not understand about current kinesis scheme is that the thumb buttons do not have diodes. Though they can generate ghost key presses at the hardware level. E.g. if (on the current kinesis) F1,F4,G are pressed at once then we should detect also T key press because there is not a diode on F1/F4.  But when I press this combination then OS does not detect T. Not sure why. Maybe firmware filters out these cases. The address decoder used to drive the matrix in kinesis probably can withstand shorts.

Now it is rare on kinesis to press two rubber keys at once, but if thumb cluster keys are on the same row with rubber keys then it is more probable to happen. Modifiers are often pressed for longer time. Though still hardly anybody presses two rubber keys at once. Still this may physically happen and if so I'm not sure ATmega32u4 can handle a short between its two output pins (one being driven as High and the second one as Low). E.g. for your condensed matrix, user presses F2,F4,End. Output Col3 is +5V, output Col4is 0V, from End we get zero on input Row6 and because there is no diode on F4 we get short of the 0V on Row6 to Col3 (which is at +5V). Will ATmega32u4 survive? If not then matrix must be drive using open collector outputs, i.e. an array of transistors needs to be added to make open collector outputs from TTL outputs.

[uberben]

That is more or less what I was thinking about doing if we needed to add buttons to the thumb keys. That or hijack the lines used for the Advantage Pro lock switches.

As for the shorting issue, here is my code that is doing the matrix scanning: https://github.com/BenBergman/tmk_keyboard/blob/uberkinesis/keyboard/uberkinesis/matrix.c

I never have any rows or columns driven with a strong 5V. They are only ever set to 0V, 5V through the internal pull-up, or left floating. This way all pins are safe from shorting out. If a 0V output pin gets shorted to a pin that is pulled high, this is what registers a keypress. If a 0V output is connected to a floating pin, that pin will now appear to be set to 0V, leading to ghosting.

So far I've not had any problems with this setup, and this is the same approach used by other people using variations of this firmware, many of which are using it on keyboards without diodes.

Does this address your concerns?

[vvp]

Right, since you do not use address decoders or shift registers you can switch off (set as input) all the lines except the one which needs to be set to GND. This way the micro-controller can simulate open collector output. So shorting is not an issue. In the worst case, there will be ghosts when 2 or more simultaneous rubber key presses are involved.

[vvp]

Taking the switch pins (and keeping the plates grounded) is probably better.
If my remarks are correct that should be pin 2 on right cluster and pin 10 on the left cluster. But I have a comment here that pin 10 on the right cluster is not connected. So just pin 10 on both thumb clusters should do.

[chrisandreae]

My existing Kinesis controller upgrade currently handles quite a lot of these features: https://github.com/chrisandreae/keyboard-firmware, and also offers more Kinesis-like functionality such as on-the-fly key remapping and macro recording. Since it drops in only to replace the existing microcontroller, it can take advantage of the onboard 74LS138 demultiplexers to scan the original matrix (so adding extra keys is simply a matter of adding entries to the matrix_to_logical_map), and the 2kb EEPROM for macro storage.

I don't see any particular difficulties adding trackpoint/trackball support, but if you want to add any more USB endpoints you'll need to switch to using the ATMega32u4+LUFA backend rather than the ATMega32+VUSB one (this was already implemented to support the Teensy-based Ergodox hardware, so shouldn't be an issue).

Rewriting the layer code to support more than the Kinesis-like two layers wouldn't be particularly hard, but is constrained by internal EEPROM size (costs 86 bytes per layer), and requires rethinking how layer switch is handled: currently it dedicates a key ("Keypad") to toggling between the two.

Swapping USB out for Bluetooth reports would be quite feasible now that iWRAP supports sending raw HID reports. Just add a separate library backend that calls into KeyboardMain() and implements USB_Perform_Update() (compare vusb_main.c and lufa-main.c).