Katy keyboard (or K80CS (Key80 Contoured Split))

[vvp]

I was asked to create a thread for this. So here it is. It is probably a bit early to create it since no fully working prototype exist yet, but whatever.

This project happened because I almost bought an ergodox but then I realized that:

1. Thumb cluster is too far away for me.
2. Especially the bottom row of the kewell is not tilted (hard to press with fingers).
3. Kinesis Advantage is missing keys and has closed firmware.

Project goals:

1. Create a bastard child of kinesis, maltron, and ergodox.
2. Prefer key reachability before placing keys in a nice matrix.
3. Use only 1x1 keycaps. If the keys are easy to reach one should not have a problem to hit them even then they are small. And it is easier to source them.
4. Don't bother with PCB for keywell. Keyboard matrix is so simple that almost anybody can connect it.
5. Make it so that a blank 105 keyboard keycap set can do (if not perfectly then at least acceptably).
6. Almost everybody has a friend who has a dirt cheap RepRap 3dPrinter. Design it for it.
7. Use Kinesis like firmware.

Description of the current milestone:

1. This is prototype version 0.6.
2. Cherry MX switches.
3. Uses modified chrisandrae's firmware.
4. Uses 2*8 alphanumeric LCD indstead of LEDs. It will indicate (caps/num/scrol)lock status) and the current layer. When macros or remaps are being defined a short help will be there.
5. Thumb cluster uses only DCS row4 keycaps. Keywell uses the proper DCS keycaps for each row. DSA keycaps are possible too.
6. Left side is the mirror image of the right side but without the LCD.
7. Left and right sides are connected with "ethernet" cable, 8 pin RJ45 jacks (though these may be replaced with 6 pin RJ25 jacks since 6 pins is enough and some noob will not be able to connect it to his ethernet hub/switch). The RJ45 socket is in the funny protuberance just above the thumb cluster.
8. SPI is used instead of I2C.
9. ATmega32u4 (at least in the first fully working prototype, maybe an ARM later).
10. The electronics inside is partially hacked PCBs and partially a "bird's nest".
11. The case is 3dPrinted using FDM (i.e. the most common RepRap) in 3 parts: bottom, top switch, top palm. The top parts are glued together then screwed to the bottom. Printed in ABS. A printer with 20x20 cm bed is enough.
12. Primary layer layout is like Kinesis Advantage with these changes:
    1. CapsLock is Escape
    2. LeftShift and Delete are swapped
    3. RightShift and Enter are swaped
    4. The new key below kinesis Delete is LeftWin
    5. The new key below kinesis Enter is RightWin
    6. The new keyb below kinesis BackSpace is LeftLayerShift
    7. The new keyb below kinesis Space is RightLayerShift
    8. Other missing keys in the two inner columns or in a non-primary layer.
13. Any keyboard tilting will be soved by 3dPrinting appropriate stands.

Later goals.

1. Better PCBs for internal stuff (no teensy or something like that, just solder ATmega32u4 (or some ARM) in TQFP package directly to PCB).
2. Support for mixed kebyoard and mouse macros running in a separate fiber (strafe jump at a single keypress anyone?). From the beginning, no in-keyboard recording (would require USB master to do it right). Maybe recorded in a PC app and loaded to the keyboard. From the beginning just predefined in code.
3. Mouse stick (maybe, not sure I want it, mouse keys will be probably enough). If it will be added then it will be on both sides. So there will be two if any.

Status:

1. Models for both sides are done but they need a bit of tweaking to ease assembly more.
2. Right hand side case is done.
3. Electronics is tested on a bread board.
4. Firmware was played with but not finished ... not even for prototype v 0.6.

Disclaimer:
This is a project for fun. If I lose interest then it is stopped regardless of the status. But there is a good chance that at least prototype v0.6 will be finished (possibly by the end of this year).

The pictures are attached. Do not pay any attention to the keycap legends. They often do not represent the primary layout which will be loaded there.

[Zekromtor]

This is my favorite bastard child to date.
How are you liking the current thumb cluster? Are you able to hit all buttons easily without pressing two at a time?

And for a 3d printer noob, how long does it take to print that whole thing out, and what is the cost of the ABS material?

[vvp]

Here is the layout of the right thumb cluster:

Code: Select all

        Alt       Control
PageUp       Shift       Space
PageDown  LayerShift   WindowKey

All the modifiers are on the thumb clusters. The modifiers are symetric between left and right thumb cluster. I like it a lot (better than the Kinesis one).
Because of height staggering, it is hard to press two of thumb cluster keys at once with only one thumb. You can do it if you consciously put your thumb in a somewhat awkward postion but it is not comfortable and people afraid of RSI would cringe at that. If you need complicated combinations use both thumbs (e.g. Shift on left thumb cluster and Alt on the right one plus an appropriate finger for the key press itself). It is easy to press a modifier key and some other keywell key with the same hand but I bet people afraid of RSI would complain about this too

The print time will depend on the printer, its configuration, the slicer used, and the exact slicer setings. But the most important parameter is the print movement speed.
Example numbers for a print speed set to 8cm/s (only as I remember them from the last print, I would like to give better numbers but cura (the slicer) is broken on my machine right now - something wrong with dependencies of the python based GUI):

• key switch part: about 5 hours
• palm part: about 2 hours
• bottom part: about 3 hours

The material cost itself (price of the used good quality filament) is about 7€ for the complete case (both sides together). Comercial 3dPrinting services will give you a better quality (also because you can use a better process e.g. SLS) but they will aslo charge a lot (I guess (never tried) a few hundreds €). If you want to 3dPrint something cheaply then you need to find a friend with a 3dPrinter or get access to some maker space or whatever exists there in the developed countries

[vvp]

The first bird-nest like electroncis passed the smoke test.
Of course, this is not expected for anybody but me for firmware developement. Building this is not for people with faint heart. The connector to the left of arduino (bellow piezo-buzzer) is JTAG 10 pin header for debugging. The part under the palm rest will be replaced by a PCB and few ribon cables. The keyboard matrix will stay as it is (manually wired, termination points going to the ribon cables).

bot-v0.6.jpg (116.87 KiB) Viewed 54071 times

top-v0.6.jpg (68.61 KiB) Viewed 54071 times

[Zekromtor]

Looks great, very neat wiring job.

[Muirium]

Yup. Hot glue could well be a good idea! Not least in a full metal case like my 60%…

My sloppy wiring + bokeh =

[vvp]

I do not know about metal plate but a bit of regular glue is a good idea in case when a switch is inserted in a 3d printed plate and manually wired. It is not neaded for many of them but it is needed for some. So it is just better to do it for all of them.
I tried 3 options how to fix the switches:

1. Hot glue gun. This did not work well. It does not hold it strong enough so I could still pull out the switch from the plate when I wanted to pull out only the keycap.
2. Two small droplets of gummy glue(*) to the opposite corners of the switch. This works fine. No way to pull out the switch out when pulling out a keycap. Yet it is still posible to pry out the switch (without trying to cut through the glue (by inserting a scalpel between the switch and the plate at the glue point)). The disadvantage is that you need to place the glue droplets into corners before inserting the switch.
3. Two very small droplets of loctite in the centers of the opposite switch socket sides. This holds stronger than the "gummy glue" version. You can do it after the switch is inserted. That is good. Now the bad: to pull out the switch you need first to insert scalpel between switch housing and the side of the switch socket. But still after pulling it out the switch and plate are not damaged in a way which would matter. Anyway I do not intend to pull out switches till they are broken so this is good enough for me.

(*) Gummy glue is some kind of glue which dries into some gummy substance instead of something stiff.

The switch matrix wiring uses 0.25 mm un-insulated copper wires. The column wires are placed just at the switch bottom. The row wires are placed at the tops of the corresponding switch pins. The height difference means that there are only a few places where an insulation needs to be put on the row wires. And that is needed because the plate is curved. Actually manually wiring the matrix turned out to be very easy this way since you can place the whole row/column wire first and then solder it all at once. The wire will hold at its place by making a loop around each solder point. Making the "bird nest" below the palm rest was a pain though. That really needs a PCB.

wiring.jpg (101.35 KiB) Viewed 54015 times

[scottc]

I have a stainless steel plate on my custom board, and I hot glued a switch hole that I needed to change. It works fine and is just as sturdy as the others.

[Muirium]

You made a custom? I don't remember seeing this…

[scottc]

I did! Well, mostly.

cus.jpg (235.45 KiB) Viewed 53961 times

This is the only picture I have right now, and I left it at a friend's house with the intention of finishing soldering it there. It's not finished yet... laziness is a powerful thing!

[Muirium]

Not too shabby! I'm guessing that weird off-centre spacebar switch position is one of the many, many things I don't understand about Cherry caps.

[scottc]

Yep, it's one of the quirks of the winkey G80-1800 (from which I got the caps): a 6U spacebar with the same mounts as a 7U, just truncated by 1U on the right. There's an entire column to the right that's obscured under my hand, too!

[Coherent]

This keyboard is amazing, thank you so much for starting this project! I also have a 3d printer and was looking at doing something like this. Do you plan to release the .STL files for this project? I'd love to collaborate!

[vvp]

STEP files will be available for a small fee (like about 15€) or possibly even completely free under something like a GPLv3 license. I'm not decided yet. You can generate STL files from STEP files if you want to but STEP files are better if you want to modify/extend it.

Everything else (firmware source code, kicad files for schemes / PCBs) will be available under a GPL or CC license. I would like to provide some build guide too (if there would be interest). So far only a few people indicated it but it is also a very early stage now.

If demand is limited I should be able to provide some pritned cases for about 140 - 200 € if people do not have better/cheaper access to a 3d printer. Quality about the same as on the pictures in this thread. If there would be more demand some group buy can be organized.

It will be released after I have a working version which is reasonably easy to build. For example it will not be immediately after v0.6 is done since I learned I need a few small changes to the case to make it easier to assemble and we definitely need a PCB for the "bird nest" circuit under the palm rest. I suppose that should be v0.7 and that can go out. It will be easy to get to v0.7 from v0.6.
I do not want to release something which is too hard to build or not working. That is the reason I want it working here first. It will be harder to make than Ergodox anyway.

If I would lose interest (or if somethng would happen to me ) then some of my friends here will take over or the git repositories will be oppened in whater stage they are at that time.

[vvp]

kko is giving his first shot at porting chrisandreae's firmware to Katy. This may take long but it is the easy part (we are software developers by craft).

Here is how it looks like when an ICSP programmer is connected to the mess (there are even much simpler ICSP programmers, you can make one from parallel port cable and few reistors):

_ICSP.jpg (275.83 KiB) Viewed 53689 times

And JTAG debugger:

_JTAG.jpg (236.44 KiB) Viewed 53689 times

[Coherent]

Great idea providing the 3d files for a small fee. I am more than happy to support awesome projects like this but I like the fact that I can print and customize the keyboard myself.

Out of curiosity, to expedite development was there a reason why you didn't use the exact same electronics schematic as the ergodox so that you didn't have to do any firmware development? You could just handwire the keys like you do here but in the same pattern as the ergodox does and then wire the teensy up the same way. I'd think that once you created the smaller circuit board you'd essentially be done. Was the decision made so that you could incorporate the LCD and make all the keys the small sized?

[vvp]

The connection to the LCD (and no LEDs otherwise) is the main reason why it differs significantly from ErgoDox.
There are other smaller differences too:

• left/right connection is different; the left side uses simple shift registers instead of I2C port expander (the main reason was that it was reported that I2C handling takes a significant time)
• SPI is used instead of I2C for EEPROM access (SPI is quicker)

We would like to save time for fibers running macros in parallel. Maybe not really needed but it does not look like the changes to make it quicker are going to be a problem.

The firmware probably will not be a big deal. At least the base part of it. kko already reported that chrisandreae's firmware is modified enough to register with OS, and it sends scand codes as keys are pressed. So the most important keyboard feature already works now. There are keyboards out there which do not have any other features than what is already done

Making EEPROM/LCD working and the other features will take longer. It should not be a big deal though. But we will not give estimates how long will the firmware modifications take. One can create usable estimates but making them takes time. We will not bother. It is not important for this project.

[vvp]

A slight detour for fun. I tried to print a keycap on a reprap! Something I did not consider to be really doable. Especially the stem. But it turned up quite well. The only post processing needed was to cut away the remains of the brim. And I painted it with acetone. It may not be needed. But it is quick, makes surface smoother, and helps layer adhesion.

keycap2.jpg (13.25 KiB) Viewed 53304 times

It sits there like a butt on a chamber-pot

keycap1.jpg (98.07 KiB) Viewed 53304 times

Awww, bad lightning. Btw, that is the left side of Katy. Almost done. Still some electronics work to do. I'll post about it later. Hopefully within a week.

[epicepee]

So what's the status of the models? Are you going to release the STLs? The STEPs? Both? I want one of these.

[vvp]

I just finished the electronics of the left side of my first hopefully working prototype v0.6.
I did not do any tests with it, not even a smoke test is done yet.

v0.6-top-L.jpg (70.27 KiB) Viewed 53213 times

v0.6-bot-L.jpg (108.95 KiB) Viewed 53213 times

There are expected no significant changes on the left side electronics. The released version should look about the same (except it should have a proper PCB instead of a universal one). But the looks of the internals will be about the same till track points are added ... on each side one ... which is very far future.

As for as the status in a more general sense:

• I want to do some small (not really that important) improvements to the case models which will make it a bit easier to assemble it.
• Right hand side hardware is working (but it needs to be put on a PCB instead of a "bird nest").
• Adding the left side support to the firmware will be easy (if the hardware will not release the magic smoke when powered up the first time ).
• Firmware for the right side works except macros xor LCD. Remap works but macros take a lot of program memory so if we add macros we need to remove LCD or vice versa. This is a preliminary report from kko.

Ok, what does it mean? I did not look at the firmware myself yet so I'm not decided how to continue. I'll check it out hopefully within this month. Then I decide how to continue. The point is that one of the primary goals for the keyboard is to provide advanced macros which can run in parallel with standard keyboard functionality. This is to settle one of my gaming itches The most probable outcome will be that we change the controller to something more advanced. We expected this to happen from the beginning since ATmega32u4 is a rather limited chip. But we did not expect it to happen so soon. It is probable that we will not even bother to design the right hand side PCB for ATmega32u4 and just go on directly to a new controller. If so then it will not be ready by the end of this year as originally estimated. Currently we are considering either ATXMEGA128A4U (ATxmega) or STM32L100RBT6 (ARM Cortex-M3). If somebody wants to provide feedback on these chips then feel free to respond.

At the near term, it can be interesting only to somebody who wants to make his own right hand side PCB and PCB mounting points on the right hand side case. That means only for people who know a bit of electronics design and also 3d design (or are willing to just somehow glue their PCB in there). Uff or somebody who wants to repeat the "bird nest" I did. But really, that is only for masochists.

On the other side it is fun that one can even 3d print keycaps on a reprap. Kko told me he wants to use Katy with 3d printed keycaps just for crazy look of it

[vvp]

The left hand side electronics works correctly, but the firmware will not fit in 32KiB of ATmega32u4; definitely not with the additional features we plan for.
We try to swap the controller with something more powerful. Especially something having more program memory. The first attempt is ATxmega128A4U. Here is our breakout board to test whether it is usable (and whether LUFA's experimental support for ATxmega is worth something).

_front.jpg (35.66 KiB) Viewed 53030 times

_back.jpg (41.76 KiB) Viewed 53030 times

It is a home etched board. I was surprised by the quality you can get at home. The toner transfer method was used. It takes about 30 - 60 minutes to etch the board. Much quicker than a commercial service
Avrdude can connect to the board. Whether we can burn a new firmware or do more with it is not know now.

[Muirium]

Nice vintage looking homemade PCB!

If you wind up in trouble, the Teensy 3.1 is quite capable, as an ARM processor with USB built in.

[vvp]

Thanks, yeah, looks good. We were amazed what can be done with almost no tools.
If some people here design their own PCBs and did not try to etch it themselves then I would recommend to try it.
The etchant should be stirred while etching ... and in a hot bath if you want it quick. We were joking about "cooking" a PCB. It was a great fun.

We loaded a led blinking firmware on it and we can debug the firmware with avrice through PDI. So it was a success. We need to check the level of LUFA support next.

[vvp]

Prototype v0.6 is done. I'm using it for about 2 weeks and it seems to be working fine. I had two instances when something strange did happen but I did not investigate. My main goal is to verify that the keywell and thumb cluster shape is OK.
It supports standard chrisandreae's firmware features except macros (program interpreter). Adding that increases program size enough that it does not fit into flash and I'm lazy to optimize it. We try to use ATxmega controller with a bigger flash instead. An ARM Cortex M3 is an option too but we first try ATxmega since it seems to be easier to port the firmware to it.
The summary of features:

• LCD support (on the picture you can see layer name in the first line and the second line contains Caps/Num/Scroll lock status and the prompt for the source key when defining a kinesis advantage like remap)
• two layers: Normal and Keypad
• layer switch and layer shift keys (I added the layer shift keys, they were not in the original firmware)
• on the fly key remap functionality (like on kinesis advantage)
• mouse keys (I returned back to a simple linear acceleration model)

I added two simple plastics bricks there as a palm support. Minecraft style! They are printed separately and only attached with a double sided duct tape.
I'm satisfied with the shape. I considered to add more column stager to the pinkie columns but decided against it at the end. My original idea was to have the least common keys at the bottom pinkie row but it is just easier to put the least used keys to the top pinkie row. There is no reason to change the column stager then.

Example layout (so that I have a key position naming later):

Code: Select all

+     1   2   3   4   5   PrntS                Pause  6   7   8   9   0   -
Tab   q   w   e   r   t   CapsL                WMenu  y   u   i   o   p   \
Esc   a   s   d   f   g   F2                      F8  h   j   k   l   ;   '
Del   z   x   c   v   b   LCtrl LAlt      RAlt RCtrl  n   m   ,   .   /   Ent
Prg   `   Int ←   →   BckSp LShft Home  PgUp RShft Space  ↓   ↑   [   ]   LaSw
                      LLaSh LWin  End   PgDn RWin  RLaSh

Reachability without even a slight move of the wrists:

• hand positioned more back
  • slight wrist move is needed to press top pinkie keys: + 1 0 -
  • keys hit at bottom half only: LCtrl RCtrl
  • slight palm tilt outward is needed for: Del Prg Ent LaSw
  • keys hit at a corner only: LAlt RAlt
• hand positioned more forward
  • slight writs move (or an awkward thumb bend) is needed for: LLaSh LWin RLaSh RWin
  • slight palm tilt outward is needed for: Del Prg Ent LaSw

I'm surprised how well the inner (index finger) column is reachable.

I tried to raise the inner edges of both halves (to get an outward tilt). But I removed that. It is not needed if I put halves next to each other and rotate them outward around a vertical ase (as seen on the picture from the top). And I use it that way. It takes less space.

I plan to do at least one more prototype (v0.7). I would like to have something better than what I already have. Though I think that the current v0.6 is better than my original Kinesis Advantage. I guess it may take about 6 months to finish v0.7. Here is the list of changes I plan to do:

• maybe change key spacing form 19.5 mm to 19 mm (not sure about this)
• small changes to the case shape (but not to the key switch positions) for easier assembly
• ATxmega (or possibly ARM Cortex M3) controller (with bigger flash)
• PCB for the right side (make PCB so that controller can be also in the left side (if somebody would want to build only left half of Katy), make it home etch-able if it is feasible at all)
• a slightly different LCD which can be positioned more to the inner edge
• LCD contrast and back-light control from firmware
• LEDs for Caps/Num/Scroll lock
• enable macros/program

If somebody wants to get the data to build v0.6 then I can prepare them in a week or two. But I do not recommend it yet. Just wait for v0.7. Only reply here or send a PM that you would like to build Katy v0.7. It will help going. Katy v0.7 will be better and will have also PCB for the right side
All the data will have some GPL like license except the case 3d model files. The case files (*.step) will cost about 15€. If you do not like it I encourage to build your own contoured case. It is not that hard and we will get more variability. That would be great.

If you would like to try to build v0.6 then here are the skills you need to pull it out:

• a bit of 3d design skill to adjust mounting points in the case (or e.g. close the LCD hole) if you decide to design a PCB for the right hand side (or dump LCD so that it is easier from electrical point of view)
• some soldering skills to build the hand wired keyboard matrix
• good soldering skills and a good ability to read electrical schemes (to build the bird nest for the right side or design a PCB for it)
• some reprap handling skills (slicers, the printing itself) if you decide to 3d print the case yourself (material cost is about 8€)

v0.6-top-fin.jpg (245.17 KiB) Viewed 52788 times

v0.6-front-fin.jpg (196.65 KiB) Viewed 52788 times

[Zekromtor]

Looks incredibly functional. Unfortunately functional doesn't garner the same internet response as sleek, now does it?
You miss having a dedicated F-key row?

[vvp]

Yeah, maybe I'll work on the sleek part too, but it must be functional first since I actually want to use it myself. And I want something well working before I want something pretty. And at least the first public version should be easily printable on a cheap reprap. That puts some limitations on Katy's shape too.
Function keys are in a separate keypad layer. Here is the keypad layer default definition:

Code: Select all

+     F1 F2  F3  F4  F5    F11                 F12  F6  F7  F8  F9  F10  -
Tab   q  w   M↑  r   t     CapsL              NumL  K/  K7  K8  K9  K-   \
Esc   a  M←  M↓  M→  g     F2                   F8  K*  K4  K5  K6  K+   '
Del   z  x   c   v   b     Mb2 LAlt      RAlt RCtrl K=  K1  K2  K3  KEnt Ent
Prg   `  Int ←   →   Mb1   Mb3  Msu      PgUp RShft K0  ↓   ↑   [   ]    LaSw
                     LLaSh LWin Msd      PgDn RWin  RLaSh

M* - keys which represnet mouse movement or clicks
K* - numeric kyepad keys 

The default (non-keypad) layer is shown in my previous post.
I quite like the F keys in the keypad layer since it is easy to hit them without looking at the keyboard and mostly without even moving my wrist (F1 and F10 need a tiny wrist movement). It is also easy to remember where they are since positions are mostly the same as the number keys. I think this is definitely better than the Kinesis Advantage rubber F keys. Whether it is better or worse than a separate F key row above the number row is arguable both ways.

One can move between layers with either layer switch key (LaSw) which behaves like Kinesis Keypad key or using layer shift key (?LaSh) which behaves like Kinesis foot pedal 1 or like Fn key on other keyboards.
The default definitions do not really matter since one can remap key positions easily using Prg-R <src> <dst> and the LCD shows small hints what needs to be done while remapping. Later, the layer definitions will be changeable/exportable/importable also using a special client application. That will be also used for advanced timed macros (e.g. a strafe jump sequence in a keyboard) and possibly also custom LED and LCD handling. But that is far future.

Current status:
Electronics and PCBs with the new controller are designed and working. The firmware is ported to them.
Compared to the stated goals for v0.7 we added a compose led too and also a photo sensor to control LCD and LED brightness based on ambient light. I hope this will work well (no support in firmware for this yet).
Next is making the planned changes to the case and building of v0.7. I believe v0.7 will be good enough to be releasable.

[Zekromtor]

What games do people macro strafe jumps in? In q3a that would be sacrilege.

Honestly, I don't think there's ever going to be a bowl-shaped keyboard that will be streamlined enough for any mainstream attention. After owning/using them for a while, you kinda forget just how alien they look to someone unfamiliar with their greatness. My keyboard has so much ugly hand cut foam and crap on it right now from tweaking the hand pads that I'm embarrassed to even take a picture of it, but that's just how it goes. My vote is for 99% weight on function, 1% on form. The types of people who have the desire and means to print the sucker out won't mind.

How do you personally choose to toggle your second layer? Momentary or toggle? And do you often hold shift and use your arrows to highlight text? Or is that mainly mouse territory for you?

[vvp]

What games do people macro strafe jumps in? In q3a that would be sacrilege.

I do not know. All quake based engines should allow strafe jumps. I do not know whether people have any macros for it. I play only COD4 (where strafe jumps are possible) and even that only once or two times a week. Not much of a gamer. But I like the idea to have a rather complicated sequence of keyboard/mouse events programmed in the keyboard

Honestly, I don't think there's ever going to be a bowl-shaped keyboard that will be streamlined enough for any mainstream attention.

I agree. I would not try to make Katy a business without improving its looks a lot and finding how to produce it very cheaply. It is just for fun. That is also why it all takes so long. I work on it only about 10 hours a week.

My keyboard has so much ugly hand cut foam and crap on it right now from tweaking the hand pads that I'm embarrassed to even take a picture of it, but that's just how it goes.

Don't worry about it provided you do not want to make it a business. If you would want to make a profit then you must make it pretty. For small consumer stuff, form (and marketing) are more important than functionality. That is also why people can make living selling "monster speaker cables" for 10 times the price of a simple low resistance 2 wire (power) cable

How do you personally choose to toggle your second layer? Momentary or toggle? And do you often hold shift and use your arrows to highlight text? Or is that mainly mouse territory for you?

I almost exclusively use LayerShift. LayerSwicth gets hardly any use.
I typically select text with Shift and Arrows and sometimes PgUp/PgDown/Home/End. Arrows are always easy to use when all modifiers are on thumbs. PgUp/PgDown/Home/End are not always easy since they are on thumbs too.

[Kaibz]

I just found out about your project vvp and i can't tell you how impressed i am.

I totally agree that it looks like the best of both the erdgodox and Kinesis advantage.

May i ask you how much programming knowledge you had before starting this project? I m asking because i am close to a noob and i wonder how hard it was to implement a working LCD into an existing firmware? Btw would it be as hard to have a 16X2 LCD implemented into it instead of 2X8 ?

Do you think it would be even possible to have a feature that change the keyboard layout when a game or application is executed ? or would it be just to complicated ? (i'm asking this to be able to customize games or applications that don't support key remaping or limit the number of keys you can remap)

I'm sorry i'm not skilled enough to give you any feedback or help on any chips like the Cortex M3, however here is the blog of an engineer who managed to build her keyboard with a LCD with a Teensy 3.1 so she might have some insight on it: http://dawnmist.dreamwidth.org/1250.html

Anyway, Great work!

[vvp]

May i ask you how much programming knowledge you had before starting this project? I m asking because i am close to a noob and i wonder how hard it was to implement a working LCD into an existing firmware? Btw would it be as hard to have a 16X2 LCD implemented into it instead of 2X8 ?

About 25 years.
It is easy to add an LCD support to a keyboard. You do not need to have much experience to do that. I guess a year of C or C++ should be plenty enough. The point is you do not need to know much to communicate with an LCD like I'm using (e.g. FDCC0802C-FLYYBW-51LK). You can find examples how to do it in e.g. Arduino libraries, directory LiquidCrystal. So you only need to adjust examples for your project.
The only problem with a bigger LCD (like 16x2) is how to place it in a keyboard so that it does not make it bigger and the LCD is visible (not under your palm). The only difference (from the software point of view) is to use different arguments when initializing the LCD.

Do you think it would be even possible to have a feature that change the keyboard layout when a game or application is executed ? or would it be just to complicated ? (i'm asking this to be able to customize games or applications that don't support key remaping or limit the number of keys you can remap)

You can define a different layer (layout) for each game. When playing a game just select the corresponding layout. I plan to add there more or less unlimited number of layouts but not in the very next release. That will probably come only with Normal and Keypad layout. Implementing the feature of unlimited layouts is not hard. Plus some support for copy/rename of layouts. Not hard too. A layout modification is already there thanks to Remap. But layouts are not a priority for me. At least the strafe jump macro will be there first. And that is much more work than unlimited layouts and the related stuff.
The controller has access to 18 kB of eeprom. Should be enough for a lot of macros and layouts.

I'm sorry i'm not skilled enough to give you any feedback or help on any chips like the Cortex M3, however here is the blog of an engineer who managed to build her keyboard with a LCD with a Teensy 3.1 so she might have some insight on it: http://dawnmist.dreamwidth.org/1250.html

I did not know about that project, but the right hand side PCB is already done and working with ATxmega. Firmware is ported. The question of controller is answered for at least v0.7. I'm quite satisfied with it. It was not much work to port the firmware from v0.6. The only thing I mind on ATxmega so far is rather flaky ADC converter. But it will do good enough. It is needed only for the light sensor. Probably a feature which some may consider an overkill anyway.

Anyway, Great work!

Thanks.