* Initial version of the Ergodox EZ Bépo keymap, TypeMatrix style.
* Update the readme file and add some handling of the keyboard LEDs.
* Toggling layer requires 2 taps.
* Remove a constant as it conflicts with an earier definition.
* Fix a typo in a type name.
* Fix the arrow layer that had a bad number.
* Second main version of my bepo keymap, after the tests of the first one.
* Fix the triggering of the function layer and the handling of the LED.
* Reduce the shining of the LEDs.
* Fix the swap layer (that required a keypress on the other side of the keyboard to be deactivated).
* Duplicate some of the mouse button for easy access.
* Move some of the secondary functions out of the center keys.
* Slightly slow down the mouse and mouse wheel.
* Update the comment and readme.md for the V2 of the keymap.
* Invert button 2 and 3 of the mouse. Really fix the SWAP layer.
* Test with the right alt modifier added as secondary function (on hold) of the space keys. The right alt key becomes a left alt one.
* Add specific shift/ctrl for the FN layer; move some mouse keys around to help with that.
* Remove one FN modifier-on-hold key that was not useful.
* Duplicate the FN layer inside the MOUSE layer.
* Add support (not tested yet) for macro recording and play on a single key as a tap dance.
* Allow to stop recording the macro by tapping once on the macro key (still un-tested).
* Add support for macro recording using some tap dance.
* shorten a comment.
* Reinstate the FN toggle on the percent key (so that there is an FN toggle on the right-hand-side).
* Fix some comments and update the link to the most up-to-date image.
* Small fix to the keymap images.
* Change overwatch to Gamepad
* Remove secrets file
* Add sample sensitive.h file
* Borrow @colinta's secrets.h include method
* Remove unnessary placeholder for macros
* Set secrets to use PROGMEM for char string
* Add readme files to my keymaps and userspace
* ignore libs
* Clang complete file
* Add VIM_A, VIM_S, VIM_COMMAND_SHIFT_D, and VIM_COMMAND_SHIFT_A
Add VIM_A, VIM_S, VIM_COMMAND_SHIFT_D, and VIM_COMMAND_SHIFT_A
a s O
* Comment blocks for minimap
generated at
http://patorjk.com/software/taag/#p=display&h=0&v=0&c=c&f=Banner&t=COMMENT
* Be explicit
* More Comment blocks
* Add J
* add A, C, D, J, S, O
* Make h j k l explicitly vim commands (useful for JOIN)
* add cb ce cw ch cj ck cl db de dw dh dj dk dl vb ve vh vj vk vl x ciw diw viw
* debug messages for ci di vi
* Var capitalized
* Save bytes by disabling mouse keys
* Add Y P
* Be more explicit about which key was pressed
* Be more explicit about which key was sent
* Move project to new directory structure
* Remove non-vim layout folder
* Replace KC_TRNS with KC_NO on normal layer
* Insert Mode as default
* Try to prevent crashes
* Put normal mode back
* Revert "ignore libs"
This reverts commit 4c5d7592d6.
* add rules.mk
* Add mouse bindings
* Checkout most recent keymap following rebase
* Realign mouse button keys
* Make a macro for TO(NORMAL_MODE)
* add i2c lib submodule
* add actuation point adjustment to fc980c
* add actuation point adjustment to fc660c also.
* use https for i2c submodule
* move to existing i2c lib
* properly remove old submodule
* oops, forgot some files for the fc660c
* Line ending stuff again
* Added initital files and layout for the PCB Ruler keyboard/macro pad thing
* Updated Readme
* Changed make command to new format
"unselecting" left-hand rows is a wasted i2c transaction.
On the left-hand side, the ergodox uses a GPIO expander. It
does *not* change "direction" (input/output) of pins, it just
sets pins high or low.
But all the pins are written at once. There's no way to
change just one pin's value; you send a full byte of all eight
row pins. (Not all of them are in use, but that doesn't matter.)
So every pin is either +V or ground. This is in contrast
with the right-hand side, which is using input mode to make pins
be neutral.
So there's no need to "deselect" the rows on the left side
at all. To select row 0, you set the GPIO register for the
rows to 0xFE. The previous code would then set it back to
0xFF, then set it to 0xFD on the next cycle. But we can just
omit the intervening step, and set it to 0xFD next cycle,
and get the same results.
And yes, I tested that the keyboard still works.
On my system, scan rate as reported by DEBUG_SCAN_RATE goes
from 445 or so to 579 or so, thus, from ~2.24ms to ~1.73ms.
Signed-off-by: seebs <seebs@seebs.net>
Koen Klinkers