| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Add keymap for smt Clueboard (HHKB layout)
* Add readme for smt Clueboard (HHKB) keymap
* Flesh out the keymap a bit more to support Colemak & Dvorak
* Update README with layout image
|
|\ \ \
| | | |
| | | | |
Change to per-key eager debouncing for ErgoDox EZ.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Empirically, waiting for N consecutive identical scans as a debouncing
strategy doesn't work very well for the ErgoDox EZ where scans are very
slow compared to most keyboards. Instead, debounce the signals by
eagerly reporting a change as soon as one scan observes it, but then
ignoring further changes from that key for the next N scans.
This is implemented by keeping an extra matrix of uint8 countdowns, such
that only keys whose countdown is currently zero are eligible to change.
When we do observe a change, we bump that key's countdown to DEBOUNCE.
During each scan, every nonzero countdown is decremented.
With this approach to debouncing, much higher debounce constants are
tolerable, because latency does not increase with the constant, and
debounce countdowns on one key do not interfere with events on other
keys. The only negative effect of increasing the constant is that the
minimum duration of a keypress increases. Perhaps I'm just extremely
unlucky w.r.t. key switch quality, but I saw occasional bounces even
with DEBOUNCE=10; with 15, I've seen none so far. That's around 47ms,
which seems like an absolutely insane amount of time for a key to be
bouncy, but at least it works.
|
|\ \ \ \
| | | | |
| | | | | |
dynamic macros: Trim the trailing modifiers; further cleanup
|
| | | | |
| | | | |
| | | | |
| | | | | |
Fixes #1199.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
More specifically, we save them and then place the `macro_end` pointer
before them so they are essentially ignored and the other macro may
freely overwrite them.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Add new keymap for dshields.
|
| | | | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
lowercase .jpg
|
| |/ / / / /
| | | | | |
| | | | | | |
i guess that fixes the image link - currently its broken
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Merge changes for coderkun’s Neo2 layout
|
| | | | | | | |
|
| |\ \ \ \ \ \ |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \ |
|
| | | | | | | | | |
|
|\ \ \ \ \ \ \ \ \
| |_|_|_|/ / / / /
|/| | | | | | | | |
[Bigtuna.IO] Updating Miuni32 Layouts
|
| |\ \ \ \ \ \ \ \ |
|
| | | | | | | | | | |
|
| | |\ \ \ \ \ \ \ \ |
|
| | | |\ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Collectively we should keep on working on the "default" layout.
I am adding my own layout to freely explore adjustments
and new features.
|
| | |\ \ \ \ \ \ \ \ \ \
| |_|/ / / / / / / / / /
|/| | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | |\ \ \ \ \ \ \ \ \ \
| | | |/ / / / / / / / /
| | |/| / / / / / / / /
| | | |/ / / / / / / / |
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \
| |/ / / / / / / / / /
|/| / / / / / / / / /
| |/ / / / / / / / / |
|
|\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | | |
[ps2avrGB] Add KEYMAP without KC-prefix
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
and remove obsolete explicit line-separator "\"
|
| | |_|_|_|/ / / / /
| |/| | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
and rename old variant to KEYMAP_KC
|
|\ \ \ \ \ \ \ \ \ \
| | |_|_|_|_|/ / / /
| |/| | | | | | | | |
Add DYN_REC_STOP to the dynamic macros, cleanup PR #1267
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
We need to check whether we just passed the after-the-end point of the
other macro. Instead we were checking whether we are going to reach it
now.
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Apparently sometimes the backlight was toggled only once and it was left on.
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Right after the user initiates the macro recording, they usually need
to release some keys used to access the DYN_REC_START layers. It makes
sense to ignore them.
Note: The keys used to access the DYN_REC_STOP key are *not* ignored.
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|