Merge branch 'dev'
still a candidate for release with keyboard :) -- still -- gona stop
saying that with every merge, lol
- the svg/html output that documents the layout looks a lot better now
- merged in a colemak layout from jjt on github
- made a make target in the toplevel to make it easy for me to generate
a sepatate .hex file for every layout (for posting to the downloads
page)
------- jjt -------
I increased the spacing of the layout sections and made all layers follow the
spacing for consistency.
I also made changes to the positions of the layer keys, added a number symbol
row on layer 1 (I found it easier to reach) and made a QWERTY layer, mostly for
gaming. And I switched the primary thumb buttons, also for gaming.
-------------------
Merge branch 'dev'
- changed the way layers are handled!
- reorganized a bunch
- updated some documentation and such
- updated USB IDs
- now compiling in OS X (though it *should* still work in linux and
windows (except the toplevel build script is unix only) - it's a bug
if it doens't)
- toplevel build script now generates a lot more, including a bunch of
information in JSON meant for the UI, and an html file thats a
currently-very-bad picture of the layout that was compiled
- rewrote the layer functions in main() (easiest way to get the to
work.. :) )
- fixed the keymap (i had the numpad keys pushing layer 2 instead of
layer 3)
- changed the numlock keycode.. i was using the wrong one, lol
- and some minor aesthetic changes
- NOT TESTED YET. still need to do that
- also, got an idea for layer masking...
possible future changes:
- i'd like to make the layer matrices just '_kb_layout_values', and
'_kb_layout_functions'.
- i'd like to make layer masks implemented with a special function
'kbfun_layermask_transparent' or something similar. a function that
looks up what would have been pressed if that layer wasn't active.
they could be chainable, i.e. a lookup for such a function could end
up calling the same function (if two layermasks were active on top of
on another), which would then call a real key. these wouldn't be
allowed on the base layer, of course... and then, all i'd have to do
to keep track of layers would be keep a variable length array (or
not... maybe an array of length 10 or something) of which layer is
active... :)
- i'd like to have a thing (this isn't a very complete thought yet)
where keypresses are looked up first in the EEPROM, to see if there's
a definition there. if there isn't (which should usually be the case)
then the standard definition for that key from the matrices would be
used. this would allow macros (and redefinitions) without reflashing.
this would also be convenient, once the mechanism was implemented, for
assigning keys multiple decomposable actions... dunno exactly how
it'll work out yet though. layer stuff comes first.
Dev Catchup Pull Request - johnfonte
(merge branch master with dev)
See commit history. Primarily:
- the build process changed a bit to make things easier for the UI
- a couple key functions were added (including code for an integrated numpad)
- a whole bunch of stuff was reorganized
- work was started on changing the way layers and layer switching are handled
- things were updated for the new PCB prototype by Fredrik (bpiphany) (and diode direction is now selectable during compilation by setting some macros in src/keyboard/ergodox/options.h)
Everything tests out on the breadboard, and with the PCB as far as I can tell. I don't know if testing has been done with a complete keyboard using the new PCB yet.
- rows are now 0..6, cols now 0..D (matching the pics Fredrik posted of
his first flippable PCB)
- either rows or columns can now be the driving pins. the option is in
".../keyboard/.../options.h"
- linked lists need to be rewritten to be more memory efficient
- all kbfun functions are now of type `(void kbfun_...(void))`, and the
arguments they need are passed via a group of global `main_arg_...`
variables (and other `main_...` variables)
- new ergodox website
- clarification in licence indicating that parts of the project may not
be under that license/copyright
- currently the stuff in src/lib, and soon the stuff in contrib,
(are|will be) under different copyrights, and possibly different
licenses.
- also, just so it's written down somewhere: some of my documentation
may be considered derivative works of the specs|docs i was taking
things from, but i hope i'm safe (fair use?). i tried to make clear
in each file where i got stuff though.