- the numpad functions are reorganized, and there are more of them now,
so the numpad can be treated either as something that's toggled or
something that's locked
- the numpad functions may need to be split into a separate file, to
keep things pretty. i'll look into it later.
- the linked-list functions are being written so that hopefully i can
change the concept of how layers (with transitions and masking) are
handled. they're incomplete in this check in because i took a break
to fix the numpad functions for dox
also added another layer to _kb_layout_release[][][], mostly NULL, but
including at least one of each available kbfun*(). this way, all the
functions appear to be used, and none of them get optimised out by the
compiler
- changed KBFUN_FUNCTION_ARGS again
- changed kbfun's
- condensed `kbfun_press()` and `kbfun_release()` to `kbfun_press_release()`
- added `kbfun_toggle()`, which toggles keycodes on or off
- added `kbfun_layer_inc_dec_press_release()` which is like
...press_release(), except it increments the layer first (and
decrements it on keyrelease)
- added `_kbfun_exec_key()` (which is a public kbfun*(), but not for
assignment to keycodes) for convenience. used by main(), and
currently 1 of the kbfun*()s. it doesn't save a lot of code, but i
think it makes things slightly easier to read. not quite as elegant
a solution as i'd like, but it might have to do
- changed keymap accordingly
- changed main()
- now using `_kbfun_exec_key()` (instead of essentially inlining the code)
- now sending the USB report once every cycle. i was sending once for
every keypress (lol, by mistake: what i meant to do was only send it
if any keys had been pressed).
so that _kb_layout_press... and ...release... are of type uint8_t
instead of kbfun_funptr_t (saving 1 byte per key per layer per matrix =
40% of the total layout size).
this brings the total firmware size with 10 layers to 6574 bytes instead
of 8302 bytes. the teensy 2.0 has 32256 bytes of flash.
i'm going to revert to the old way. partly because the space savings
don't seem consequential compared to what we have to work with. mostly
because doing it with an array separates the function pointer to macro
(or const var) correlation in qwerty.c, and because i then have to
extern the _kb_layout_functions[6] array in layout.h (or qwerty.h).
also, using an enum instead of macros with manually assigned numbers
corresponding to the array indices would be more error prone, i think,
because (since it has to be visible outside qwerty.c) it would have to
be declared in a header.
hopefully all that makes sense. i'm in a bit of a hurry. but look at
the code: i think, even with a bit of formatting help, it'd still look
less clean
- addition to references.md
- keymap modification
- now using 2 shifts => capslock
- the previous capslock key -> tab
- the previous tab key -> left bracket
- bug and omission fixes; notably:
- _is_pressed() no longer changes the value of
`keyboard_modifier_keys`, lol
- kbfun_2_keys_capslock_press_release() now works. (capslock doesn't
register if left or right shift is pressed, so the shift state has
to be stored, cleared, capslock pressed, and shift state restored)
- main() no longer locally overwrites the value of `current_layer`
before sending it to the kbfun. (i didn't realize i was using the
same variable name for two different things)
- improvements
- kbfun_layer_inc() and ...dec() are now variable
there is now a toplevel makefile for making dist, so that we can keep
the project build systems separate (in src and contrib/UI*), and then
build dist from the root dir
before, if you pressed a key, then shifted layers, then released it, the
first layer's press() would be called, and the 2nd layer's release()
would be called, causing keys to stick, and probably other errors. now,
the layer that the key was on when it was pressed is kept track of, and
the proper release() is called.
also, layers can be shifted per key now, instead of just for the whole
board at once
i also changed how keyboard-private includes are handled. "private"
stuff is now in its own file, instead of being nested in an extra
`#ifdef`.
and i think that's it. i'm pretty tired right now, so there may be
errors, but it seemed to work all right with cursory tests.
without this we have ghosting problems on the bottommost keys of the
teensy side
thanks to hasu (on geekhack) for the suggestion, and PrinsValium for
confirming erratic behavior with his firmware without these delays.
thanks DOX for making the changes and trying it out. i'm just adding it
to the repo.
new usb library (my attempt at implementing mouse keys and nkro) in (slow)
progress
a few larger things
- new makefile
- added descriptions to most entries in the references.md file
- moved keyboard layouts to program space
- updated for DOX's PCB! :) see the last PCB update checkin for details
- added high-level (logical) led macros, so that the top level firmware
doens't need to know what numbers leds are (or how many there are)
- left low-level (processor specific) led macros in
keyboard/.../teensy-2-0.h , where they were
- put non processor|layout specific led macros in keyboard/.../led.h
- put layout specific led macros into keyboard/.../layout/*.h (with
default empty macro definitions in keyboard/.../layout.h)
also
- cleaned up some typos and such
- moved the debounce time macro to 'keyboard/ergodox.h', since it's
technically keyboard (keyswitch) specific
aggregate changes for PCB update
- documentation updated to reflect that the columns are now the driving
pins, and the columns are the read pins. both are still treated as
open drain.
- macros for led pins 1 and 2 were swapped
- update functions now cycle through columns->low, read rows
- added a matrix macro to map from how we want the key layouts
represented, to how things are scanned into the matrix
(plus a few small aesthetic things in /src/keyboard. i changed some
function like macros to lower-case, because someday they might be
implemented as real functions... and there's no real reason to
distinguish between functions and function like macros in the main() and
other higher level code. at least that's what it seems like to me right
now.)