- 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.
- 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)
- 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).
- 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
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.
(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.)
apparently, sublists need to be indented 4 spaces (1 tab) or more to be
recognized as such (because subsequent lines of a list may be indented
up to 3 spaces). it's right there on the markdown syntax page, but i
didn't catch it the first time.
- made short keycode macros for the USB keycodes (under "lib/...")
- refactored "keyboard/.../layout.c", to make way for multiple layouts,
and to make it easier to read (by using short keycode macros)
- layout.h has a computed include line now, and the code (and layout
specific header stuff) is in a subdirectory. the makefile should
take care of which layout gets included and compiled
- changed kbfun_press() and kbfun_release() to be able to handle the
modifier keys (instead of requiring a separate function for the
modifiers)
- added a makefile variable for which keyboard gets compiled. even
though there's only one right now
- simple bug fix in kbfun_press() and kbfun_release()
- no longer check for previous init() in the mcp23018 functions;
something would happen when i tried to read from it, sometimes, when
it'd been unplugged or stoped some other way, and it would hang - and
the only thing that would make it better was running the test_twi_2
function (a series of writes, with stops after each). so now
mcp23018_init() is a series of writes, with stops after each. it
doesn't take appreciably longer to run... maybe it should be looked
into later though.
- changed the main() loop a little
also, mcp23018_init() needs fixing: `twi_stop()` needs to be at the end
of transmission blocks. i wouldn't think that would be necessary, but
it seems to be the only thing that'll make it work, and it also seems
consistent with the protocol diagram in the datasheet (lol, imagine
that), so i think that's what i'll have to do. not as though it matters
much i guess, since it's a single master / single slave system anyway, i
was just hoping not to release the bus till i was finished..
- fixed some includes (`uint8_t` comes from a header, not the language)
- put code from some of the .h files into .c files
- now using open drain logic (hi-Z or GND) on both chips instead of
driving the row pins high on the teensy, or using a pull-up resistor
on the row pins with the mcp23018
- put `return 0;` at the end of some functions that weren't void
- fixed/updated some documentation; esp. the row assignments for the
mcp23018
- generalized the unused/row/column pin assignment and init code using
macros, so they'll be much easier to move around if necessary
- fixed a redefinition error in "lib/usb/keyboard-usage-page.h"
also, i didn't make a note of it in the *.md file, but Waveform
Generation Mode 15 for fast PWM wasn't working right (well.. wasn't
working how i expected it to). i misinterpreted what the modes were
doing, partially (haha, or all-ly?) because i didn't read the
description of fast pwm thoroughly enough... in any case, all the
information's in the datasheet, and it's actually not terribly long.
i'm not sure how to correctly use Mode 15 yet, but i think i'll leave it
alone for now, since Mode 5 works as expected, and i think what the
datasheet says about *that* makes enough sense to me for me to be
content for the moment.
Ben Blazak
Ben Blazak