This adds the `ACTION_TAP_DANCE_DUAL_ROLE` helper, which makes it easy to have
keys that act as a key on the first tap, and as a layer toggle on the second.
Fixes#1532, reported by @Ptomerty.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
[Colemak Mod-DH](https://colemakmods.github.io/mod-dh/) layout for
users keeping an `azerty` layout configuration on their OS.
The symbols layers was done after analysing various programming
languages sources codes and should be close to optimal for typing
confort.
The let's split code used delays in its debouncing algorithm which
increases input latency. This commit copies and adapts the code from
`quantum/matrix.c` to lets_split's `matrix.c`.
This protocol breaks out "duplicate" keys into their own entry in the packet so that more complicated logic can be done on the software side, including support for additional languages and alternative theories.
Requires virtser; Allows QMK to speak the TX BOlt protocol used by stenography machines and software (such as Plover). The upside is that Plover can be configured to listen only to TX Bolt allow the keyboard to switch layers without need to enable/disable the Plover software, or to have a second non-Steno keyboard work concurrently.
* merge
* line ending stuff
* Added MiniDox keyboard folder / configs / and some keymaps
* Updated minidox rev1 config, and readme. Also updated that_canadian keymap to include RGB
* cleaned up that_canadian keymap comments
* Fixed RGB being enabled by default, now it must be turned on at the keymap level
This introduces a grep dependency, which I believe we didn't have
before, but it should be available and installed by default on all the
supported systems.
This is a setup that is very useful for me. It may or may not be for
you. I will use it in conjunction with the A5 overlayed sv_SE layout.
The layout is subject to change (in particular I'm thinking about adding
a macro recording feature), but it have not changed much the past year
or two so you can expect it to be stable enough to learn it.
A5: http://aoeu.info/s/dvorak/svorak
My xkb map: https://github.com/lindhe/dotfiles/blob/master/usr/share/X11/xkb/symbols/se-A5
The most major points:
======================
L0:
---
* Easily accessible F11 key for fullscreening
* Print screen
* Middle mouse button for X-paste
* Improved reachability of meta buttons (LCtrl, LALt, AltGr, LGui etc.)
* Cluster Page Up/Down + Home/End by the right thumb
* Vim-like arrow layout in right bottom row
* Set media layer toggle to right thumb (Enter)
* Set apostrophe on LCtl (putting it next to some other small
characters)
L1:
---
* Full function key layout
* Teensy button
L2:
---
* Improved media buttons layout (close by the jkl; Vim binding)
* Improved layout of emulated mouse buttons
LED behaviour to binary+CAPS
============================
The ErgoDox LEDs on this layout is using the two rightmost LEDs as the
two LSB in a two digit binary number, representing layer 0, 1, 2 and 3.
The leftmost byte/LED indicates CAPS status.
Instead of having all sendstring keycode mappings in the main quantum.c
file, give each one its own file in keymap_extras that can be #included
in a user's keymap. If one is included, it will define the appropriate
lookup tables and overwrite the weak definitions in quantum.c.
(Including more than one sendstring definition will fail at compile
time.)
Update @rai-suta's test keymap to match, as well as the documentation.
Refactor new-ish JIS_KEYCODE send_string implementation with existing
send_string
Reshuffle JIS in line with other alternative keycodes for sendstring,
and make them all accessible via compile-time options
Add a separate function to allow sending a string with a delay.
* Move Space Caded Parentheses to own layer
The space cadet parentheses where too much distracting. Therefore they are now on the function layer. I also added two more layers for also having angle brackets and curly braces on the shift keys forr better access.
Also updated the README
* Fixed SHIFT+Function key conflict
* Removed Angle Bracket and Curly Bracket layers, as they don't work corrrectly
*NOTE:* it might still be desirable to set the software layout to sv_SE in your
OS.
Swedish (sv_SE) Qwerty layout for ErgoDox, based on the Default configuration
I have tried making this as close of a match I could between the [default
ErgoDox EZ configuration](https://ergodox-ez.com/pages/our-firmware) and a
standard Swedish Qwerty layout.
Notable differences from default:
=================================
* There are three special character buttons (acute accent, circumflex/tilde and
apostrophe/asterisk) that don't have any buttons to map to naturally. I've put
these at other places:
* Acute accent (´) can be found in the lower left corner, conveniently
placed to reach for making an é.
* Apostrophe (') was put in the lower left corner, close to acute accent.
* Circumflex (^) and asterisk (*) was placed in the lower right corner.
* Tilde (~) and diaeresis (¨) I couldn't find a good place for, so I left
those out. I could only get the buttons to produce a single one of the
characters. How can I get it to work properly?
* The Alt button on right thumb was exchanged for AltGr (RAlt).
* I changed the backslash in the numpad (layer 1) for a minus. Thought it was
more sensible.
* I didn't find a good place for the "<>|" button, so that one was left out.
That is a problem that really needs to be resolved. Pipe can be found on layer
one, however.
* allow mod swapping for mod tap
* quick include
* fix the mod swapping
* make changes consistent with action code
* fix bug
* re-enable no gui, etc
* fix binary comps
* solid logic
* Added orthodox
* Modified readme
* Modified readme
* Modified readme
* Updated makefile
* Fixed keymap issues
* Modified serial communications to allow for over 8 columns
* Fixed sizeof command
* Fixed some typing issues
* Testing issue #1191 (n-column split i2c slave)
Based on initial OrthoDox (serial) config by @reddragond and others,
this attempts to add TWI (I2C) support.
Relevant: <https://github.com/qmk/qmk_firmware/issues/1191>
- per @ahtn recommendation, using memcpy for moving slave matrix
into slave sending buffer
- slave buffer has been enlarged using sizeof(matrix_row_t)
- note: i2c.h now includes matrix.h
- note: matrix.c includes <string.h>
* Added i2c keymap - right col still not working
* orthodox: re-added i2c keymap, based on serial
* orthodox / issue #1191: trying 9-bit serial
- orthodox serial protocol now sends 9 bits per row, instead of 16.
Technically it's using MATRIX_COLS, so it might work generically.
- ROW_MASK is #defined in serial.c to truncate the checksums to prevent
overflows causing false errors. This macro should be renamed if it's
kept.
* Revert "Fixed sizeof command"
This reverts commit f62a5b9939d6a9c0e442ec403de00c14431a55f9.
Changes had been made to the lets_split serial driver for testing which
mirrored the multi-byte-row changes made to support the orthodox. As the
lets_split does not require these changes, and new improvements had
been added to the orthodox port only, this commit reverts them.
Because the new code could potentially reduce latency over the serial
transport, it may be desirable to re-add in the future, by backporting
the current working orthodox code.
* orthodox: default serial keymap improvements
- formatting has been improved
- a few keys have been shifted, mainly in Raise and Lower layers,
to be more like the default Planck layout
- Now available: F12, Home, End, PgUp, PgDn, Media-Next, Media-Play
Still To Do:
- duplicate for TWI
- Alt modifier
- GUI modifier
* orthodox: failed attempt at 16b/row TWI
- duplicated updated serial keymap for "i2c"
- removed string.h/memcpy, instead
- hardcoded copying of six bytes per update
- still doesn't work; master reports interconnect errors on txled
* orthodox: adjusted default keymap
- this is applied to both 'serial' and 'i2c' keymaps
- Alt and GUI have been added, as they were missing
- comma and period persist across more layers; Home/PgUp and End/PgDn
have been moved slightly to accommodate
* orthodox: revert TWI support to minimum to debug
- disabled ssd1306 and hardware locking in build configuration
- increased TWI buffer from 0x10 to 0x20 bytes
- decreased TWI clock from 400000 to 100000
- removed hardcoded TWI multi-byte sending/receiving
An 'i2c' build of this was found to work on a rev1 Orthodox, although
slave-side col9 was understandably not working. When testing-time
permits, features will be gradually re-enabled towards getting the full
matrix supported over TWI.
* orthodox: TWI (i2c) is working, kludge for col9
The TWI interconnect ("i2c" in directories and build config) is now
working for the Orthodox, including the slave half's column #9.
This is intended as an interim solution, as it's a kludge, not a fix.
Rather than a working multi-byte implementation, the two col9 keys'
bits are packed-into and unpacked-from the two unused bits in row1.
Furthermore, the TWI clock constant has been reduced to 100000 from
400000, as testing revealed the higher value just didn't work.
Testing also found that (with this kludge) increasing the TWI buffer
was not necessary.
This commit leaves many commented-out lines in matrix.c from previous
testing, which will be removed in a future commit once the
interconnects' multi-byte problems have been debugged more thoroughly.
* orthodox: updated readme.md
The readme for the Orthodox now includes a description of the keyboard,
allusions to its author and availability, a linked photo, and links to
the evolving build guide and the current keymap on KLE.
This update has been prepared with /u/Deductivemonkee's assistance.
Added basic description of the keyboard and some build and configuration
instructions.
Also moved the RGB underlight modification instructions to the readme.
The previous default configuration and keymap was made for a Phantom
modified with RGB underlight.
This commit makes the default more in line with the "official"
configurations provided by the PCB.
The previous default have been moved to a separate keymap named
`rgbmod`. It has also been updated to better match the template keymap.
It's a little unclear what the style guidelines are for the QMK project.
But I figured that I should at least keep the indentation consistent
within the KMAC part.
Previously KEYMAP referred to the KEYMAP_ARROW layout and had 45 keys. It makes
more sense for the default keymap to be the 44 key layout, as is implied by the
name.
Additionally keymaps for all other known layouts have been added:
KEYMAP - base layout
KEYMAP_ARROW - additional key in bottom right
KEYMAP_COMMAND - additional key in bottom left
KEYMAP_ARROW_COMMAND - combination of KEYMAP_ARROW and KEYMAP_COMMAND
* Make submodules point to qmk
* Update uGFX to 2.7
* Use ugfx with custom fixes
* Fix the ChibiOs submodule commit hash
To match the hashes in the mabl/ChibiOS and therefore QMK repository.
* Add MIDI layer
* Respect brightness level on layer signalling
* Add hotkey in control layer for signalling state
* Update layout.png
* Remove image and replace it with imgur link
* SCKLCK is now SCROLLLOCK
Yes, with all three Ls
At least it doesn't have a random K anymore lol
* Removed strange mystery trailing numbers in the docs
* Fix layer LED signalling in magicmonty keymap
* Include the breathing modes in layer signalling
* Reverts mode to 1 as the other modes flicker
* Add Cursor keys on VIM positions and PAUSE to function layer
If a macro play key is inadvertently recorded in a dynamic macro
a loop is created and the macro will not terminate when played.
This should be prevented.
* Add 80ms delay for KC_CAPS when used as a tap key
Workaround for the macOS caps lock delay
* Revert "Increase TAPPING_TERM for the Clueboard"
This reverts commit a74e69e9fa.
* 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
Replacement controller for Filco Majestouch 2 104 key keyboard. BE
advises code will also work with the Black Petal controller - I don't
have one to test with. Tests working perfectly on my Filco.
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.
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.
From the official docs:
```
Note: The official Debian and Ubuntu images automatically run apt-get clean, so explicit invocation is not required.
```
Also added ` && rm -rf /var/lib/apt/lists/*` as part of the install line which probably does what was intended (no need to make a new layer).
Added apt-get update to the RUN payload, as it should be part of the same layer.
Both are documented here: https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/
Dynamic macro functionality is modified to check for `DYN_REC_STOP`, so
that macro recording can be stopped with a designated key combination
(e.g. `qs` or anything) instead of mandating the use of a `_DYN` layer.
`_DYN` layer stopping can still be done by passing `DYN_REC_STOP` within
`process_record_user()`:
bool process_record_user(uint16_t keycode, keyrecord_t *record) {
uint16_t macro_kc = (keycode == MO(_DYN) ? DYN_REC_STOP : keycode);
if (!process_record_dynamic_macro(macro_kc, record)) {
return false;
}
return true;
}
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.
Using only one layer, and activating it with two keys at the moment.
As with previous comments, this isn't final, but is a good starting point for a one-handed keyboard, half a Planck-like ortholinear keyboard, or a sample to show a layout with a function layer.
There was a typo, so the attempted configuration proably didn't do
what it should have done. I think it left the pin floating, and
could cause the LCD problems issue-1230.
It turns out that the ChibiOS K20 SPI driver doesn't handle the
chip select, so it needs to be done manually. Acquiring the bus is
not enough since the pin was in the wrong mode. This is now fixed.
Also increase the frequency of the SPI from around 200kHz to nearly
20 Mhz.
No animation, display led statuses and layer name on the same screen
Don't display layer bitmap
Fully saturated colors for caps, less saturated ones normally
Added MOD_TAP aliases for keymap.c readability.
Updated README to document said changes.
Added additional Dvorak layer to make using the CMD key easier on Macs.
fixed issue where Default.c "function key" does not work (actually it's changing my LED steps). Changed layout to be more user friendly for people that use the standard spacebar milled top plate.
* Clarify the license for files we have signoff on
* Update against the currently signed off files
* Remove unused and not clearly licensed headers
* Replace an #endif I accidentally removed while resolving merge conflicts
As per Pramod's comment on stack overflow:
In C int foo() and int foo(void) are different functions. int foo()
accepts an arbitrary number of arguments, while int foo(void) accepts 0
arguments. In C++ they mean the same thing. I suggest that you use void
consistently when you mean no arguments.
Refactored Bluetooth support to make adding new Bluetooth modules
easier in the future.
* Remove `OUT_BLE` key from QMK's keymap. `OUT_BT` is all we need now
as there's no difference anymore.
* Made BLUETOOTH_ENABLE build option legacy as not to break existing
keymaps (Falls back to existing EZ Key support if on)
* Removed `ADAFRUIT_BLE_ENABLE` build option
* Created new build option `BLUETOOTH` with module option (Currently
`AdafruitEZKey` & `AdafruitBLE`)
* Moved all LUFA bluetooth key/mouse events under `BLUETOOTH_ENABLE`
ifdef with selected modules output.
This only applies to keymaps that has combined esc/grave. Here we call it theKEY.
Think about the motion when we do shift + theKEY (typing ~), or CMD + theKEY (switching window on MAC). Based on the original code, we must do following sequence: press shift -> press theKEY -> release theKEY -> release shift. However, it is very possible and natural that we do this stroke sequence instead: press shift -> press theKEY -> release shift -> release theKEY.
If we do the 2nd stroke sequence, the code will del_key(ESC) instead of (GRV) when we release theKEY. This caused some inconvenient issues and ghost typing.
By adding a flag, this issue is eliminated and will not affect any other functions.
A simple addition to the `install_dependencies` script which remaps the debian dependencies to their freebsd package-names. After a recursive clone and using gmake, I can successfully build all firmware from the root directory (minus some warnings generated by gcc-4.9.4 which I can procure on request). however there is a problem running tests.
Removed some unneeded keys from raise and lower layers
moved the + and = signs, backspace is now more intuitive
moved all the Function keys to CUSTOM layer
added ctrl alt del to CUSTOM layer
simplified the layout picture greatly
Update existing keymaps to enable MIDI_BASIC functionality. Also added
an option MIDI_ENABLE_STRICT to be strict about keycode use (which also
reduces memory footprint at runtime)
tone array:
text data bss dec hex filename
0 25698 0 25698 6462 satan_newsboytko.hex
0x6480 bytes written into 0x7000 bytes memory (89.73%).
note on array:
text data bss dec hex filename
0 25802 0 25802 64ca satan_newsboytko.hex
0x6500 bytes written into 0x7000 bytes memory (90.18%).
if you compare split_util.h with the original project by ahtn, the
address we look for isLeftHand config went from addr 7 to addr 10
(decimal). The EEP files were not updated.
EE_HANDS should not be enabled by default since it's more confusing for
most users
Added new keymap `Admiral Strokers` to the Satan keyboard. This is an
ISO based layout with tap for brackets/ curly on shft and ctl keys.
Furthermore, there is added arrows and media/volume/special/f-keys layer
on the TAB button when you hold.
The previous two options were COL2ROW, ROW2COL; this adds CUSTOM_MATRIX
to disable the built-in matrix scanning code.
Most notably, this obviates the need to set MATRIX_ROW_PINS or
MATRIX_COL_PINS.
since the keycode for a tap dance process gets process only after the
TAPPING_TERM timeout, you really only have ONESHOT_TIMEOUT -
TAPPING_TERM time to tap or double tap on the key. This fix save the
oneshot_mods into the action.state structure and applies the mods with
the keycode when it's registered. It also unregisters the mod when the
the tap dance process gets reset.
The oneshot cancellation code do not depend on the
action_tapping_process and since process_record get called via the
action_tapping_process logic moved the oneshot cancellation code into
the action_exec function just before the action_tapping_process call
Scenario:
Locking the KC_LSHIFT, and then using a tap dance key that registers a
S(KC_9) will unregister the KC_LSHIFT.
The tap dance or any keycode that is registered should not have the
side effect of cancelling a locked moditifier. We should be using a
similar logic as the TMK codes in tmk_core/comman/action.c:158.
A macro key can now be easily set to act as a modifier on hold, and
press a shifted key when tapped. Or to switch layers when held, and
again press a shifted key when tapped.
Various other helper defines have been created which send macros when
the key is pressed, released and tapped, cleaning up the
action_get_macro function inside keymap definitions.
The layer switching macros require a GCC extension - 'compound
statements enclosed within parentheses'. The use of this extension is
already present within the macro subsystem of this project, so its use
in this commit should not cause any additional issues.
MACRO_NONE had to be cast to a (macro_t*) to suppress compiler
warnings within some tapping macros.
* master:
Clarify license on abnt2 keymap (#1038)
replace jackhumbert with qmk
Add gitter image, start update to qmk org
Remove COLEMAK from preonic_keycodes enum
layer defines to enum
Update readme for smt Preonic keymap
Add smt keymap for Preonic
updated all the other keymaps to support the new changes.
fix: infinity60 keyboard was not using quantum features.
Compare Makefile with itself instead of using `--help`
In register_code16 and unregister_code16 we call register_code and
unregister_code twice, once for the mods and once for the keycode.
The (un)register_code have many check to see that keycode we have sent
however because we know that we are sending it a mods key, why not
just skip all of it and call (un)register_mods instead. This will skip
alot of checks and should speedup the loop a little.
the quantum matrix codes where not being initialized or/and called
so no feature of the quantum firmware could be used. These codes have
been added and now we can enjoy the quantum firmware goodness.
* Add HOME/END keys as upper/lower on arrow-up/down
* Reduce .hex file size by turning off unneeded options
* Put digit keypad onto left hand upon RAISE; this will sometimes be preferable to double-hits of right hand
* Moved duplicated defines out of inappropriate source files (matrix
pins in keymap subdirectory)
* Eliminated default keymap directory
* Hardcoded serial keymap to use serial defines and EE_CONFIG
* Hardcoded i2c keymap to use i2c defines
- Swiss German Ergodox layout:
Added ENTER key to left keyboard half on media layer
such that the enter key is available on both halves to
be able to flash both halves without an additional keyboard.
- Add Swiss German layout for Ergodox Infinity based on default
layout for Ergodox EZ.
- Minor changes in the event loop to prevent flashing display
background lights.
Since we can't read the real_mods and oneshot_mods static variable
directly within the update_user_visualizer_state
function (Threading and serial link). We are know storing the mods
states in the visualizer_keyboard_status_t structure. We can now
display the status of the modifier keys on the LCD display.
After setting a ONESHOT_TIMEOUT value, the oneshot layer state would
not expire without an event being triggered (key pressed). The reason
was that in the process_record function we would return priort to
execute the process_action function if it detected a NOEVENT cycle. The
process_action contained the codes to timeout the oneshot layer state.
The codes to clear the oneshot layer state have been move just in
front of where we check for the NOEVENT cycle in the process_record
function.
Removed Alt on base layer, replaced with Function layer.
Moved function keys to left hand. Added mouse keys to right hand on the function layer.
Moved middle click on gaming layer to be consistent with mouse layer.
Added macro _USER. Macro contents are not implemented yet.
new file: keyboards/ergodox/keymaps/ishigoya-jp/img/keyboard-layout-jpL.png
new file: keyboards/ergodox/keymaps/ishigoya-jp/img/keyboard-layout-numL.png
modified: keyboards/ergodox/keymaps/ishigoya-jp/keymap.c
new file: keyboards/ergodox/keymaps/ishigoya-jp/readme.md
Fix memory leaks by using stack instead of malloc
Reduce memory usage by having less temporary bufffers
Remove warnings by adding includes
Decrease code size by 608 bytes (mostly due to not linking malloc)
More robust handling of buffer overflows
Miscellaneous
=============
* `µ` can now be entered with UCIS.
* `™` can now be entered with UCIS.
Tools
=====
* `tools/hid-commands` can now find Banshee, and prefers it over Kodi.
* `tools/hid-commands` can now find Chrome too, not juts Chromium.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
There are a lot of PS/2 commands, some are vendor/device specific, so we
provide a weak ps2_mouse_init_user() to be implemented in each keyboard
that need it.
There are a lot of PS/2 commands, some are vendor/device specific, so we
provide a weak ps2_mouse_init_user() to be implemented in each keyboard
that need it.
There are now 3 potential locations to send HID reports:
1. USB
2. The bluefruit easy key
3. Adafruit BLE
Generally speaking, if USB is connected then we should prefer to
send the reports there; it is generally the best channel for this.
The bluefruit module has no feedback about bluetooth connectivity
so the code must speculatively send reports over both USB and bluetooth.
The BLE module has connectivity feedback. In general we want to
prefer to send HID reports over USB while connected there, even
if BLE is connected. Except that it is convenient to force them
over BLE while testing the implementation.
This policy has been extracted out into a where_to_send function
which returns a bitmask of which of the channels should be used.
This implements some helper functions that allow sending key reports
to an SPI based Bluetooth Low Energy module, such as the Adafruit
Feather 32u4 Bluefruit LE.
There is some plumbing required in lufa.c to enable this; that
is in a follow-on commit.
Unlike the arduino functions, these don't take abstract pin numbers,
they take pin labels like `B0`. Also, rather than taking very
generic parameter names, these take slightly more descriptive
enum values.
These improve the clarity of code that would otherwise be inscrutable
bit manipulation in tersely named port register names.
Adopt the macros for saving/restoring the interrupt state
that are provided by the avr gcc environment.
Removing intialization of the timer value; this shaves off
a few bytes because globals are default initialized to zero.
Define a default TAPPING_TERM in quantum.c, for keyboards that do not
have it set. Fixes the CI failure.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
When one holds a Space Cadet shift, to have it act as a shift, so that
mouse behaviour changes, when released without any other key pressed, it
still registers a paren. To remedy this, add a hold timeout: if the key
is held longer than TAPPING_TERM, it will not register the parens.
Fixes#884, with the side-effect of not being able to have parens
trigger the OS-side repeat anymore.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Plover's steno support likes quasi-qwerty, and gaming likes qwerty,
and I like dvorak, so... what if I could have it all?
Signed-off-by: seebs <seebs@seebs.net>
At this point, I consider the batch scripts @IBNobody and I worked on to mostly be a failure. They've proven to be unreliable, too dependent on the environment they're being run in, and I've seen far too many examples of people having frustrating issues with them that I haven't been able to help them with. They can also produce misleading and confusing error messages. I've been pointing people to use the WSL for a while now. Eventually, I think we should make a proper replacement for the batch scripts, possibly with an environment in msys2. For now, the WSL method in Windows 10 is far more reliable, and is easy to set up.
I also cleaned up some things in the WSL instructions themselves.
new file: keyboards/lets_splitv2/Makefile
new file: keyboards/lets_splitv2/config.h
new file: keyboards/lets_splitv2/i2c.c
new file: keyboards/lets_splitv2/i2c.h
new file: keyboards/lets_splitv2/imgs/split-keyboard-i2c-schematic.png
new file: keyboards/lets_splitv2/imgs/split-keyboard-serial-schematic.png
new file: keyboards/lets_splitv2/keymaps/default/keymap.c
new file: keyboards/lets_splitv2/lets_split.c
new file: keyboards/lets_splitv2/lets_split.h
new file: keyboards/lets_splitv2/matrix.c
new file: keyboards/lets_splitv2/pro_micro.h
new file: keyboards/lets_splitv2/readme.md
new file: keyboards/lets_splitv2/serial.c
new file: keyboards/lets_splitv2/serial.h
new file: keyboards/lets_splitv2/split_util.c
new file: keyboards/lets_splitv2/split_util.h
new file: keyboards/maxipad/Makefile
new file: keyboards/maxipad/config.h
new file: keyboards/maxipad/keymaps/default/Makefile
new file: keyboards/maxipad/keymaps/default/config.h
new file: keyboards/maxipad/keymaps/default/keymap.c
new file: keyboards/maxipad/keymaps/default/readme.md
new file: keyboards/maxipad/maxipad.c
new file: keyboards/maxipad/maxipad.h
new file: keyboards/maxipad/readme.md
* upstream/master: (1239 commits)
Update ez.c
removes planck/rev3 temporarily
Move hand_swap_config to ez.c, removes error for infinity
Update Makefile
ergodox: Update algernon's keymap to v1.9
Added VS Code dir to .gitignore
Support the Pegasus Hoof controller.
[Jack & Erez] Simplifies and documents TO
add readme
use wait_ms instead of _delay_ms
add messenger
init keymap
Add example keymap
Adding whiskey_tango_foxtrot_capslock ergodox keymap
Unicode map framework. Allow unicode up to 0xFFFFF using separate mapping table
CIE 1931 dim curve
Apply the dim curve to the RGB output
Update the Cluecard readme files
Tune snake and knight intervals for Cluecard
Tunable RGB light intervals
...
Overall changes
===============
* `F12` was replaced by an `Fx` key, that activate the **Media** layer
as a one-shot layer, and also `Alt` as a one-shot modifier.
Base layer changes
==================
* The `Media Stop` key is now a tap-dance key, and resets the device for
programming on the fourth tap.
Miscellaneous
=============
* `π` can now be entered with UCIS.
* `🐁` can now be entered with UCIS.
Tools
=====
* The `tools/layer-notify` tool was removed, it was an example, which I
don't use.
`tools/hid-commands`
--------------------
* Now looks at the `DISABLE_APPSEL_START` environment value, and does
not display an AppSel notification if it is non-empty.
* Will attempt to re-program the keyboard when receiving a `reflash`
command.
* No longer tries to select Emacs 24 on `APPSEL_EMACS`, rather, it goes
for any Emacs.
* The `APPSEL_MUSIC` command now includes Kodi in the list too, as the
last choice.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Rewrote QWERTY to make it a first-class citizen instead of just a glorified game layer.
Added a lot of keys to Extend layer to bring it in line with my Atreus.
Plenty of other changes too.
ADORE
-----
* Major rearrangements were made, to reduce pinky use, and to balance
out the hand usage.
Tools
-----
* The `hid-commands` tool will now display a notification when
the **AppSel** layer is triggered.
* The `log-to-heatmap.py` tool now treats the innermost keys on the
bottom row as thumb keys, as far as statistics are concerned.
Miscellaneous
-------------
* Fixed the **Steno** toggle key.
* My wife is now present on the keyboard too.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Overall changes
===============
* The number row has been completely rearranged on both the **Base** and
the **ADORE** layers.
* The number/function key behavior was changed: function keys are now on
the **Media**.
* The `:`/`;` and `-`/`_` keys were put back to their thumb position on
the bottom row, on both the **Base** and **ADORE** layers.
* The bottom large keys on the inner side of each half now function as
[tmux](http://tmux.github.io/) keys: the left to send the prefix, the
right to send the `display-panes` key. The left also doubles as a GNU
screen prefix key, and sends `C-a` when double tapped.
* A number of functions, such as the **AppSel** layer, now require the
`hid-commands` tool to be running, with the output of `hid_listen`
being piped to it.
ADORE
=====
* `Y` and `X` have been swapped again.
Media/Navigation layer
======================
* The function keys are now on this layer.
* Mouse keys have been removed.
* Media start/stop/prev/next have been removed.
* `Print screen` has been removed.
* There is only one screen lock key now.
Heatmap
=======
* Fixed a few issues in the finger-stats calculation.
* The tool now also timestamps and saves all input lines to a logfile,
which it loads on start, allowing one to continue the collection after
upgrading the tool.
* The heatmap tool will now colorize the stats by default.
* The periodic stats are now printed in a more compact format.
Tools
=====
* Added a new tool, `tools/layer-notify` that listens to layer change
events on the HID console, and pops up a notification on layer
changes.
* Another new tool, `tools/text-to-log.py` has been added that converts
arbitrary text to a keylogger output, which can be fed to the heatmap
generator.
* A number of features have been moved to the `tools/hid-commands`
utility. These generally are OS dependent, and are easier to implement
on the software side.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
User print disables the normal print messages in the body of QMK/TMK
code and is meant as a lightweight alternative to NOPRINT. Use it when
you only want to do a spot of debugging but lack flash resources for
allowing all of the codebase to print (and store their wasteful
strings).
- remove media-space and media-shift-space; put a play/pause key at media-m instead
- add print screen, scroll lock, and pause/break to the media layer
And in the readme:
- don't say we don't have any Windows-specific keys
- add mnemonics for thumb-alt and thumb-ctrl positioning
There was an odd case, which confused the hell out of tap-dance: suppose
you had a number of tap-dance keys, on a layer, and as part of the
tap-dance, you turned that layer off - or had it on one-shot to begin
with. In this case, the keydown event would trigger the tap-dance key,
but the keyup would not. This had two funky consequences:
- tap-dance did not correctly register that the dance has ended.
- pressing any other tap-dance key would interrupt the previous
tap-dance, and potentially input unwanted characters.
To fix this, we simply do not start a tap-dance sequence on keyup, only
when it is pressed. This way the previous sequence has enough time to
time-out and finish properly, and we don't get confused.
This fixesalgernon/ergodox-layout#107.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
There may be cases where one would like to know the current Unicode
input mode, without having to keep track of it themselves. Add a
function that does just this.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
During the build system refactor, support for enabling UCIS seems to
have been lost. This little patch adds that back, so that keymaps using
UCIS can be compiled again.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
* Switched Tab and Super on the default layout
* Moved Shift on Extend to pinky
* Moved Caps Lock to upper right corner
* Moved gaming toggle to avoid blocking Escape
Major changes include:
Base layer changes
------------------
* The parentheses & bracket keys have been merged: tapping them results
in `[` or `{` (if it was shifted), double tapping leads to `(`.
* The `:;` and `-_` keys are now available on the base layer, on
their **ADORE** location, too, just below `[{(`/`]})`.
* The `Apps` key has been replaced by `F12`.
* The `-`/`_` is no longer a tap-dance key.
ADORE layer changes
-------------------
* Adjustments were made to the **ADORE** layer, to separate some
inconvenient combinations.
Miscellaneous changes
---------------------
* `LEAD u` now starts the symbolic unicode input system, instead of the
OS-one.
* The mouse acceleration keys on the **Navigation and Media* layer have
been turned into toggles: tap them once to turn them on, until tapped
again. Tapping an accelerator button will turn all the others off.
* When the **ARROW** layer is on, the *red* and *blue* LEDs light up
now.
Heatmap
-------
* The built-in keylogger has been greatly enhanced, it now outputs the
pressed state, and the layer (Dvorak or ADORE). As such, the
`ADORE_AUTOLOG` option has been removed, instead there is
`AUTOLOG_ENABLE` now, which when enabled, makes the keylogger start
when the keyboard boots. It defaults to off.
* The heatmap generator received a lot of updates.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
In order to not declare the same variable in multiple objects (which
happens when building UCIS-enabled keymap for both the ErgoDox EZ and
the ErgoDox Infinity), move the declaration to the .c file, and keep
only an extern reference in the header.
Many thanks to @fredizzimo for spotting the error in Travis, and
suggesting the fix.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
When running make from either a keyboard folder or a subproject
it runs all keymaps for all subprojects and the selected subproject
respectively. Without this fix, the same doesn't happen if your
run make clean for example. As it would just provide you with an
error message. Now this will work as expected.
This adds an action, `ACTION_SWAP_HANDS`, that swaps the the keys on the keyboard across a keymap-defined hemisphere in order to support one-hand typing without requiring a separate one-handed layer. See updated `doc/keymap.md` for more information.
It has been required for a while now, and now actually checked in
the makefiles. Before, if you didn't have it installed it would
just recompile everything.
The readme hasn't been updated to reflect this, I think we need
to go through that separately, and see what's really needed. Or
just instruct people to run the batch scripts.
A single keyboard is always by default compiled in verbose mode.
While multiple keyboards are compiled in silent mode. This can be
overriden by the silent variable from the command line
These functions register not only the 8bit keycode, but the modifiers
too. It doesn't handle the full range of the upper 8bits, just the mods,
but that's a good start.
Changed the tap-dance pair functions to use these, so one can do:
`ACTION_TAP_DANCE_DOUBLE (KC_COLN, KC_SCLN)`
...and that will do the right thing.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This reworks how the tap-dance feature works: instead of one global
state, we have a state for each tap-dance key, so we can cancel them
when another tap-dance key is in flight. This fixes#527.
Since we have a state for each key, we can avoid situation where a keyup
would mess with our global state. This fixes#563.
And while here, we also make sure to fire events only once, and this
fixes#574.
There is one breaking change, though: tap-dance debugging support was
removed, because dumping the whole state would increase the firmware
size too much. Any keymap that made use of this, will have to be
updated (but there's no such keymap in the repo).
Also, there's a nice trick used in this rework: we need to iterate
through tap_dance_actions in a few places, to check for timeouts, and so
on. For this, we'd need to know the size of the array. We can't discover
that at compile-time, because tap-dance gets compiled separately. We'd
like to avoid having to terminate the list with a sentinel value,
because that would require updates to all keymaps that use the feature.
So, we keep track of the highest tap-dance code seen so far, and iterate
until that index.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Include `action_tapping.h`, so the keymap does not have to define a
`TAPPING_TERM` for us, and we can use the default.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
When entering unicode codes, use some delay, so the OS has time to
process the information. This is not needed on all systems, but some
seem to require it.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
It turns out that register_hex32 did not work reliably, and some systems
only allow 7 chars after the unicode magic sequence, while others allow
8. To remedy the situation, store the codes as strings, and type those
in instead of doing bit shifting magic.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Extract out the part of `qk_ucis_start` that inputs the placeholder
symbol, and make it weak, so it can be overridden.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
If the symbol name being entered is longer than the max, stop recording
it, and stop processing keycodes apart from the ones that can delete,
finish or cancel the sequence.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The purpose of this change is to allow keymaps to specify a dictionary
of unicode symbol name to code mappings, and let the person at the
keyboard enter unicode symbols by name.
This is done by having a way to trigger unicode symbol input mode, when
all keys are cached until Esc, Enter or Space are pressed. Once that
happens, we try to look up the symbol from our lookup table. If found,
we erase back, and type the unicode magic in to get that symbol. If not
found, we still erase back, start unicode input mode, and replay what
the user typed in.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This moves the unicode input start / end sequences into their own
functions, so keymaps and other functionality can build on it too.
At the same time, it changes how the Linux variant works, to match
reality: CTRL+SHIFT must be unregistered too, and we close the thing
with a Space instead.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
All keymaps that were included in VinnyCordeiro's repository were ported to QMK.
Main Readme was copied over from VC's repo, slightly altered.
Main Makefile was updated to reflect VC's original configuration.
Small changes in felix keymap.
In the header, this was defined as `set_unicode_input_mode`, but the
implementation had `set_unicode_mode` for a name. Changed the
implementation to match the header.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Major changes include:
* The **1HAND** layer has been removed.
* A `Delete` key is now available on the right thumb cluster.
* The **ADORE** layer received a major update, see the updated layout
image.
* It is now possible to enable automatic logging for the **ADORE**
layer, by setting the `ADORE_AUTOLOG` makefile variable to `yes` when
compiling the keymap. It is off by default.
* The `~` key and the `Media Next/Prev` key have been swapped on
the **base** layer.
* On the **ARROW** layer, `Backspace` has been replaced by `Enter`.
* There is some experimental support for entering Unicode symbols.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of using a thumb shift, I was given the idea of using the pinky keys as dual-role keys that also send the Shift keypress.
This gives me a Shift key on each hand again, but it will make me learn to Shift with opposite hands after all.
* Adding my own keymaps to the following keyboards:
Planck, Preonic, Atreus, Ergodox
* Delete dvorak.png
Not reflective of my layout.
* Delete readme.md
file cleanup, removing file that doesn't apply to my layout.
* Delete old_keymap.c
file cleanup
* Delete README.md
file clean up.
* Delete README.md
file cleanup
* Delete keymap.c
file cleanup
* Changed behavior of _DVORAK layout's KC_RSFT to SFT_T(KC_ENT) for flexibility's sake.
Updated the rest of the keymap to reflect the current (as of 19:37 on 08 Aug 2018) default
layout and default makefile.
Checking for ARCH is not good enough, since some subprojects define it.
Ergodox Ez for example. The leads to running the make from
keyboards/ergodox/ez failing. The keyboard makefile will not be included
in that case, and therefore not the CUSTOM_MATRIX either.
Furthermore the output files are read from many different .build
directories, so it doesn't fail deterministically. For example on the
Travis CI the compilation passes, since there's no outdated objects that
needs recompilation.
Some links were still pointing to `/keyboards/ergodox_ez`, while the
directory is `/keyboards/erdogox` now.
Not all references have been updated, and some of the text here and
there may need updating to mention the ErgoDox Infinity too, but that's
out of the scope for this quick fix.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
* When toggling the key logging on or off, the LEDs will do a little dance.
* The keylogger is now optional, but enabled by default. Use `KEYLOGGER_ENABLE=no` on the `make` command line to disable it.
* The `TAB`/`ARRW` key was turned into a tap-dance key, allowing one to toggle the **ARROW** layer on by double-tapping, and as such, avoid the need to hold the key.
* The `-`/`_` key was turned into a tap-dance key too.
* There is now a way to travel time with the keyboard, toggle the feature on by hitting `LEAD t`.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of `&& false`, explicitly `exit 1` to make the rules using these macros
fail. This fixes#571, and likely breaks Travis badly.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Atreus: Removed home row Shift. It's under the thumb anyway. Also replaced dual modifier keys with macro keys (cut, copy, paste, undo).
Ergodox: Made Colemak the default layer instead of Dvorak. Also began the process of bringing it in line with the Atreus layout I've been working on.
Removes a number of duplicated code, by passing actions around instead
of keycodes, so the various dance action functions do not have to look
up the action, but the caller does that for them.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Refactored the code a little, so all callbacks now receive a `user_data`
pointer, which can be anything. As an example, the key pairs from
`ACTION_TAP_DANCE_DOUBLE` now use this, and custom, built-in functions.
This makes it easier to extend the tap dance functionality, and also
simplifies the code a little.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
With this change, tap dance will now store the pressed state of the
tap-dance key, and allow one to make an action sooner, while the key is
still held, and only unregister when the key is released.
The registration must happen in the `on_dance_finished` callback, while
unregistering goes to `on_reset`. The surrounding code makes sure not to
call either multiple times.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This change adjusts the KEYMAP() function to provide a more visual representation of the key positions on the keyboard. Previously, keymaps have been defined directly using arrays for the Atreus keyboard. While this works, it doesn't utilize the helpful KEYMAP() function at all to allow the user to visually position the key codes for ease of editing. See the Ergodox-EZ KEYMAP() function and layouts for a great example of how this can work.
This change should not break any existing Atreus layouts. At the time of this commit, there are two existing layouts for the Atreus board, and neither use the KEYMAP() function.
This change adjusts the KEYMAP() function to provide a more visual representation of the key positions on the keyboard. Previously, keymaps have been defined directly using arrays for the Atreus keyboard. While this works, it doesn't utilize the helpful KEYMAP() function at all to allow the user to visually position the key codes for ease of editing. See the Ergodox-EZ KEYMAP() function and layouts for a great example of how this can work.
This change should not break any existing Atreus layouts. At the time of this commit, there are two existing layouts for the Atreus board, and neither use the KEYMAP() function.
This updates my ErgoDox EZ layout to v1.3, which has the following
noteworthy changes:
* Added support for logging keys, by pressing `LEAD d`. Also included is
a tool to generate a **heatmap** out of the logs.
* The arrow and navigation keys were rearranged again, and now require
an additional key being held to activate. See the **base layer** for
an image that shows where arrows are.
* The **experimental** layer has been redone, and is now
called **ADORE**, and as such, can be enabled by `LEAD a` now.
* Switching between Dvorak and ADORE is now persisted into EEPROM, and
survives a reboot.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
when using tap dance, we have the `regular` callback that is called on
the last tap. this commit adds an `anyway` callback that is called on
every tap, and a `reset` callback that is called on reset of the tap
dance taps.
Modified the LUFA USB HID Descriptor to change the logical/usage
minimums for System Control from 0x01 (Mouse) to 0x81 (System Power
Down), this fixes OS X recognizing the Planck as having a mouse and
tablet, even with mousekeys off.
The prerequisites at the start of the build process are order-only
so that the trget don't link again. Also added as a dependency to
the compilation to force the messages to be printed at the start
Moves RGB controls out of the macro function and assigns them their own
keycodes:
RGB_TOG (toggle on/off)
RGB_MOD (mode step)
RGB_HUI (increase hue)
RGB_HUD (decrease hue)
RGB_SAI (increase saturation)
RGB_SAD (decrease saturation)
RGB_VAI (increase brightness)
RGB_VAD (decrease brightness)
Allows you to press RSHIFT to cancel the insertion of a "(" when holding down LSHIFT. Alternatively, allows you to press LSHIFT to cancel the insertion of a ")" when holding down RSHIFT. This change enables you to renege from outputting a character should you press a shift key erroneously.
* Add ChibiOS packages to the avr_setup script
* Add git as a dependency
* Rename avr_setup.sh -> install_dependencies.sh
Also fix the Vagrant welcome message to reflect the new directory
structure.
* Modularity and gcc warnings fixes.
* Add ChibiOS support (USB stack + support files).
* Make usb_main more USB_DRIVER #define independent.
* Move chibios to tool.
* Implement jump-to-bootloader.
* Small updates.
* Fix bootloader-jump compiling.
* Move AVR specific sleep_led.c into avr.
* Add basic sleep_led for chibios.
* Update chibios README.
* NKRO fixes.
* Rename some Makefile defines.
* Move STM32 bootloader address config to separate .h file.
* Add ARM Teensies bootloader code.
* Fix chibios/usb_main GET_REPORT handing.
* Add missing #include to keymap.c.
* Make bootmagic.c code portable (_delay_ms -> wait_ms).
* Move declaration of keymap_config.
Should really not declare variables in .h files - since it's included
in different .c files, a proper linker then complains that the same
variable is declared more than once (once for each .c file that the
offending .h is included in).
* Add eeprom support for chibios/kinetis.
* Rename chibios example keyboard.
* Move chibios/cortex selection to local Makefiles.
* Chibios: use WFI in idle. WIP suspend stuff.
* ChibiOS/kinetis: sending remote wakeup.
* ChibiOS/STM32: send remote wakeup.
* Fix report size of boot protocol.
* Fix drop key stroke
Keyboard report should be checked if its transfer finishs successfully.
Otherwise key stroke can be missing when other key event occurs
before the last report transfer is done.
Boot protocol 10ms interval probably causes this problem in case
it receives key events in a row within the period. NKRO protocol
suffers less or nothing due to its interval 1ms.
* Chibios/usb_main: rename a variable for clarity.
* Add correct chibios/bootloader_jump for infinity KB.
* ChibiOS: make reset request more CMSISy.
* Chibios: Add breathing sleep LED on Kinetis MCUs.
* ChibiOS: Update infinity bootloader code to match updated ChibiOS.
* ChibiOS: prettify/document sleep_led code.
* Chibios: Remove the wait in the main loop.
* Add maple mini code.
* Do timeout when writing to CONSOLE EP queue.
Fixes TMK bug #266.
* Chibios: add 'core/protocol' to the makefiles' search path.
* Chibios: Update to new USB API.
* Chibios: add more guards for transmitting (fix a deadlock bug).
* Add update for chibios in README
* Chibios: Fix a HardFault bug (wait after start).
* Chibios: cleanup usb_main code.
* Chibios: Revert common.mk change (fix AVR linking problem).
* core: Fix chibios user compile options
Compile options can be defined in project Makefile such as UDEFS, UADEFS, UINCDIR, ULIBDIR and ULIBS.
* Sysv format for ChibiOS arm-none-eabi-size
Some new patches to ChibiOS puts heap as it's own section. So the
berkeley format is now useless, as the heap will be included in the
BSS report. The sysv format displays the bss size correctly.
* Fix hard-coded path of CHIBIOS
* Add support for new version of ChibiOS and Contrib
The Kinetis support has moved to a separate Contrib repository in
the newest version of Chibios. There has also been some structure
changes. So this adds support for those, while maintaining back-
wards compability.
* Update ChibiOS instructions
* Chibios: implement sleep LED for STM32.
* Chibios: Update the main chibios README.
* Chibios: fix STM32_BOOTLOADER_ADDRESS name.
* Chibios: make the default bootloader_jump redefinable (weak).
* Chibios: disable LTO (link-time optimisation).
With LTO enabled, sometimes things fail for mysterious reasons
(e.g. bootloader jump on WF with LEDs enabled), just because the
linker optimisation is too aggressive.
* Chibios: add default location for chibios-contrib.
* ChibiOS: update mk to match chibios/master.
* ChibiOS: update instructions.md.
* Add chibi_onekey example.
* Add comments to chibi_onekey Makefile.
* Rename some Makefile defines.
* Move STM32 bootloader address config to separate .h file.
* Rename chibios example keyboard.
* Move chibios/cortex selection to local Makefiles.
* Add Teensy LC onekey example.
* Chibios: use WFI in idle. WIP suspend stuff.
* Update chibi/teensy instructions.
* Update chibios/Teensy instructions.
* Add infinity_chibios
* Add keymap_hasu.c
* Infinity_chibios: select correct bootloader_jump.
* Infinity_chibios: improve comments.
* Add generic STM32F103C8T6 example.
* Add maple mini code.
* STM32F103x fixes.
* Add maple mini pinout pic.
* Chibios: updates for 3.0.4 git.
* Chibios: rename example stm32_onekey -> stm32_f072_onekey.
* Chibios: add makefiles for Teensy 3.x examples.
* Chibios: update Teensy 3.x instructions.
* Chibios: Tsy LC is cortex-m0plus.
* Chibios: add more guards for transmitting (fix a deadlock bug).
* Change README for chibios
* Chibios: update examples to current chibios git.
Match the changes in mainline chibios:
- update chconf.h
- update supplied ld scripts structure
- update Teensy instructions (switch to official
chibios and introduce contrib)
* Add ChibiOS and ChibiOS-Contrib submodules
Also fix the makefile path for them.
* Moves chibios keyboards to keyboards folder
* First version of ChibiOS compilation
Only the stm32_f072_onkey keyboard is ported at the moment. It
compiles, but still doesn't link.
* More chibios fixes
It now compiles without warnings and links
* Move the teensy_lc_onekey to the keyboards folder
* Clean up the make file rule structure
* Remove keymap_fn_to_action
* Update more ChibiOS keyboards to QMK
Most of them does not compile at the moment though.
* Use older version of Chibios libraries
The newest ones have problems with compilation
* Remove USB_UNCONFIGURED event
It isn't present in the older version of ChibiOS
* Fix the infinity_chibios compilation
* Fix potentially uninitialized variable
* Add missing include
* Fix the ChibiOS makefile
* Fix some Chibios keyboard compilation
* Revert the rules.mk file back to master version
* Combine the chibios and AVR makefiles
With just the required overrides in the respective platform
specific one.
* Slight makefile restrucuring
Platform specific compiler options
* Move avr specific targets out of the main rules
* Fix ChibiOS objcopy
The ChibiOS objcopy needs different parameters, so the parameters
are moved to the corresponding platform rule file
* Fix the objcopy for real this time
The comands were moved around, so chibios used avr and the ohter
way around.
Also change the objsize output format
* Fix the thumb flags
* Fix the infinity hasu keymap
* Per platform cpp flags
* Add gcc-arm-none-eabi package to travis
* Add arm-none-eabi-newlib to travis
* Fix the name of the libnewlib-arm-none-eabi lib
* Fix the ChibiOS paths
So that they are properly relative, and builds don't generate
extra folders
* Fix the board path of stm32_f103_onekey
* Only consider folders with Makefiles as subproject
* non-working commit
* working
* subprojects implemented for planck
* pass a subproject variable through to c
* consolidates clueboard revisions
* thanks for letting me know about conflicts..
* turn off audio for yang's
* corrects starting paths for subprojects
* messing around with travis
* semicolon
* travis script
* travis script
* script for travis
* correct directory (probably), amend files to commit
* remove origin before adding
* git pull, correct syntax
* git checkout
* git pull origin branch
* where are we?
* where are we?
* merging
* force things to happen
* adds commit message, adds add
* rebase, no commit message
* rebase branch
* idk!
* try just pull
* fetch - merge
* specify repo branch
* checkout
* goddammit
* merge? idk
* pls
* after all
* don't split up keyboards
* syntax
* adds quick for all-keyboards
* trying out new script
* script update
* lowercase
* all keyboards
* stop replacing compiled.hex automatically
* adds if statement
* skip automated build branches
* forces push to automated build branch
* throw an add in there
* upstream?
* adds AUTOGEN
* ignore all .hex files again
* testing out new repo
* global ident
* generate script, keyboard_keymap.hex
* skip generation for now, print pandoc info, submodule update
* try trusty
* and sudo
* try generate
* updates subprojects to keyboards
* no idea
* updates to keyboards
* cleans up clueboard stuff
* setup to use local readme
* updates cluepad, planck experimental
* remove extra led.c [ci skip]
* audio and midi moved over to separate files
* chording, leader, unicode separated
* consolidate each [skip ci]
* correct include
* quantum: Add a tap dance feature (#451)
* quantum: Add a tap dance feature
With this feature one can specify keys that behave differently, based on
the amount of times they have been tapped, and when interrupted, they
get handled before the interrupter.
To make it clear how this is different from `ACTION_FUNCTION_TAP`, lets
explore a certain setup! We want one key to send `Space` on single tap,
but `Enter` on double-tap.
With `ACTION_FUNCTION_TAP`, it is quite a rain-dance to set this up, and
has the problem that when the sequence is interrupted, the interrupting
key will be send first. Thus, `SPC a` will result in `a SPC` being sent,
if they are typed within `TAPPING_TERM`. With the tap dance feature,
that'll come out as `SPC a`, correctly.
The implementation hooks into two parts of the system, to achieve this:
into `process_record_quantum()`, and the matrix scan. We need the latter
to be able to time out a tap sequence even when a key is not being
pressed, so `SPC` alone will time out and register after `TAPPING_TERM`
time.
But lets start with how to use it, first!
First, you will need `TAP_DANCE_ENABLE=yes` in your `Makefile`, because
the feature is disabled by default. This adds a little less than 1k to
the firmware size. Next, you will want to define some tap-dance keys,
which is easiest to do with the `TD()` macro, that - similar to `F()`,
takes a number, which will later be used as an index into the
`tap_dance_actions` array.
This array specifies what actions shall be taken when a tap-dance key is
in action. Currently, there are two possible options:
* `ACTION_TAP_DANCE_DOUBLE(kc1, kc2)`: Sends the `kc1` keycode when
tapped once, `kc2` otherwise.
* `ACTION_TAP_DANCE_FN(fn)`: Calls the specified function - defined in
the user keymap - with the current state of the tap-dance action.
The first option is enough for a lot of cases, that just want dual
roles. For example, `ACTION_TAP_DANCE(KC_SPC, KC_ENT)` will result in
`Space` being sent on single-tap, `Enter` otherwise.
And that's the bulk of it!
Do note, however, that this implementation does have some consequences:
keys do not register until either they reach the tapping ceiling, or
they time out. This means that if you hold the key, nothing happens, no
repeat, no nothing. It is possible to detect held state, and register an
action then too, but that's not implemented yet. Keys also unregister
immediately after being registered, so you can't even hold the second
tap. This is intentional, to be consistent.
And now, on to the explanation of how it works!
The main entry point is `process_tap_dance()`, called from
`process_record_quantum()`, which is run for every keypress, and our
handler gets to run early. This function checks whether the key pressed
is a tap-dance key. If it is not, and a tap-dance was in action, we
handle that first, and enqueue the newly pressed key. If it is a
tap-dance key, then we check if it is the same as the already active
one (if there's one active, that is). If it is not, we fire off the old
one first, then register the new one. If it was the same, we increment
the counter and the timer.
This means that you have `TAPPING_TERM` time to tap the key again, you
do not have to input all the taps within that timeframe. This allows for
longer tap counts, with minimal impact on responsiveness.
Our next stop is `matrix_scan_tap_dance()`. This handles the timeout of
tap-dance keys.
For the sake of flexibility, tap-dance actions can be either a pair of
keycodes, or a user function. The latter allows one to handle higher tap
counts, or do extra things, like blink the LEDs, fiddle with the
backlighting, and so on. This is accomplished by using an union, and
some clever macros.
In the end, lets see a full example!
```c
enum {
CT_SE = 0,
CT_CLN,
CT_EGG
};
/* Have the above three on the keymap, TD(CT_SE), etc... */
void dance_cln (qk_tap_dance_state_t *state) {
if (state->count == 1) {
register_code (KC_RSFT);
register_code (KC_SCLN);
unregister_code (KC_SCLN);
unregister_code (KC_RSFT);
} else {
register_code (KC_SCLN);
unregister_code (KC_SCLN);
reset_tap_dance (state);
}
}
void dance_egg (qk_tap_dance_state_t *state) {
if (state->count >= 100) {
SEND_STRING ("Safety dance!");
reset_tap_dance (state);
}
}
const qk_tap_dance_action_t tap_dance_actions[] = {
[CT_SE] = ACTION_TAP_DANCE_DOUBLE (KC_SPC, KC_ENT)
,[CT_CLN] = ACTION_TAP_DANCE_FN (dance_cln)
,[CT_EGG] = ACTION_TAP_DANCE_FN (dance_egg)
};
```
This addresses #426.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
* hhkb: Fix the build with the new tap-dance feature
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
* tap_dance: Move process_tap_dance further down
Process the tap dance stuff after midi and audio, because those don't
process keycodes, but row/col positions.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
* tap_dance: Use conditionals instead of dummy functions
To be consistent with how the rest of the quantum features are
implemented, use ifdefs instead of dummy functions.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
* Merge branch 'master' into quantum-keypress-process
# Conflicts:
# Makefile
# keyboards/planck/rev3/config.h
# keyboards/planck/rev4/config.h
* update build script
* non-working commit
* working
* subprojects implemented for planck
* pass a subproject variable through to c
* consolidates clueboard revisions
* thanks for letting me know about conflicts..
* turn off audio for yang's
* corrects starting paths for subprojects
* messing around with travis
* semicolon
* travis script
* travis script
* script for travis
* correct directory (probably), amend files to commit
* remove origin before adding
* git pull, correct syntax
* git checkout
* git pull origin branch
* where are we?
* where are we?
* merging
* force things to happen
* adds commit message, adds add
* rebase, no commit message
* rebase branch
* idk!
* try just pull
* fetch - merge
* specify repo branch
* checkout
* goddammit
* merge? idk
* pls
* after all
* don't split up keyboards
* syntax
* adds quick for all-keyboards
* trying out new script
* script update
* lowercase
* all keyboards
* stop replacing compiled.hex automatically
* adds if statement
* skip automated build branches
* forces push to automated build branch
* throw an add in there
* upstream?
* adds AUTOGEN
* ignore all .hex files again
* testing out new repo
* global ident
* generate script, keyboard_keymap.hex
* skip generation for now, print pandoc info, submodule update
* try trusty
* and sudo
* try generate
* updates subprojects to keyboards
* no idea
* updates to keyboards
* cleans up clueboard stuff
* setup to use local readme
* updates cluepad, planck experimental
* remove extra led.c [ci skip]
* disable power up for now
* config files updates
* makefile updates
* .h file updates, config tuning
* disable audio for yang
* Update setup script 1 for new folder structure
* Improve script 1 output
* Launch elevate if run without admin privileges
* Improve MinGW error message
* Improvements and fixes to second script
* Log elevate output in first script
Noticeable changes since the last pull request:
* The forced NKRO mode can be easily toggled off at compile-time, to
make the firmware compatible with certain operating systems.
* The `:;` key has changed behaviour: to access the `;` symbol, the key
needs to be double-tapped, instead of shifted.
* The `=` and `\` keys were swapped, `=` moved to the home row, on both
the **base** and the **experimental** layers.
* The arrow and navigation keys were redone, they are now more
accessible, but the navigation keys require an extra tap to access.
* The **Emacs** layer is gone, replaced by a simplified
**navigation and media** layer.
* `LEAD v` types the firmware version, and the keymap version.
* On the **experimental** layer, the `L` and `Q`, and the `K` and `G`
keys were swapped.
* The **Steno** layer gained a few more `#` and `*` keys, to make it
easier on my fingers.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
I haven't had a chance to update the Arch base box in a while so using the Ubuntu one is far more likely to succeed for a new user (I did test that box recently as I traded my ErgoDox EZ to a friend and needed to reprogram it for him).
Unfortunately the supported targets, like "quick", "all", "clean",
and so on has to be repeated two extra times, but this is the best
I can do with my makefile skills.
* Added WS2812 support for KC60
* Reorganized WS2812 support into its own keymap
* Fixed relative link in README
* Moved WS2812 mention in README to the bottom
* Fixed titling in WS2812 README
* Reverted KC60 Makefile and default keymap back
* Moved RGB specific config.h to ws2812 keymap folder
* Added my personal keymap
* Updated compiled hex
* Reverted KC60 files to 3f6fac47 before pull request #419
* Added WS2812 support for KC60
* Reorganized WS2812 support into its own keymap
* Fixed relative link in README
* Moved WS2812 mention in README to the bottom
* Fixed titling in WS2812 README
* Reverted KC60 Makefile and default keymap back
* Moved RGB specific config.h to ws2812 keymap folder
* More documentation
* Saving crontab for user on host
* Restructuring in keeping with recent changes to conventions
* Simplify submitting my fave cbbrowne keystroke by using SEND_STRING()
* Local change, not apropos to have in this repo
* Simplify logic; no need to return so much
* Add in a version key
* Add docs
* Split build date into a separate DEFINE
* Ensure there is a value even if not working within a git repo
* Should not include the compiled code in the repo
* compiled.hex files should not be included in the repo; they represent generated compiled code
* Fix spelling in comment
* Remove more generated files
* Add rule to ignore contents of .build directories; their contents are generated
* Revert removals of compiled files
Compared to the previous version, the following noteworthy changes have
been made to the keymap:
* The keyboard starts in NKRO mode, bootmagic and other things are
disabled.
* A STENO layer was added, to be used with Plover.
* An experimental layout was added, something halfway between Dvorak and
Capewell-Dvorak. A work in progress.
* `LEAD y` types \o/.
* Some keys on the BASE layer have been moved around:
- `?` moved to the left pinky, left of `Q`.
- `=` shifted one row down, but `F11` stayed where it was.
- `-` on the left half was replaced by `Tab`.
- `Tab`'s original position is taken by a `Media Next`/`Media Prev`
key.
- `:` now inputs `;` when shifted.
* `ESC` cancels the **HUN** layer too, not just modifiers.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This adds the keyboard and keymap built, along with the QMK firmware's
git hash (or a timestamp), to OPT_DEFS. That, in turn, allows keymaps to
make use of these information, and do whatever they want with it. For
example, one could print them on `LEADER v` like this:
```c
SEQ_ONE_KEY (KC_V) {
SEND_STRING (QMK_KEYBOARD "/" QMK_KEYMAP " @ " QMK_VERSION);
}
```
This addresses #366.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
* Don't save the ctags file in the repo.
* Initial support for the KC60 board. Only 5x5 working so far.
* Rename because this isn't the same KC60 as others.
* Add in some generic layout.
Pins seem to be in the right order except the 6th column spews
gibberish.
* Don't need this for now.
* Move this to some other folder.
* Trying again to start over.
* Don't need to start over because I figured out why the 'broken' stuff wasn't working.
* Attempt to enable backlighting. It's on on pin B7 like other boards.
* Fix last port changes and fix LED control in keymap.
* Trying some other LED code.
* Bootloader needs to be bigger. Disabling backlight for now.
* Simplify LED code while I try to figure it out.
* Turn back on backlighting.
* Backlighting works now. Just need to get levels or breathing working.
* Trying to allow for turning off the LEDs before I get to brightness levels.
* The missing link: need to run the init_ports function for LEDs to work properly.
* Removing breathing stuff since it bricks the board.
* Clean up default layer.
* Cleanup keymap, KC60 doesn't support a 5th right bottom-row button.
* Add in the keymap I want for now.
* Back to escape by default.
* Move my personal keymap to the new place for keymaps.
* Add the version number for clarity.
* adds support for GH60 Satan keyboard
ANSI 125 layout, capslock and backlight implemented, support for
WS2812LED strip included
* added Phantom and GH60 Satan to travis
* More documentation
* Saving crontab for user on host
* Restructuring in keeping with recent changes to conventions
* Simplify submitting my fave cbbrowne keystroke by using SEND_STRING()
* Local change, not apropos to have in this repo
* Simplify logic; no need to return so much
* .build containment implemented
* no destructive variable setting - builds in either folder
* make from 3 places
* cleans before each build
* make from root with keyboard=keyboard, keymap=keymap
* make from keyboard/keyboard with keymap=keymap
* make from keymaps/keymap
* only implemented on planck
* adds color diag to avr-gcc
* makefiles for all plancks, clean-up
* quick build-all makefile for plancks
* reformatting of make output (colors)
* color toggle, tmk path corrections
* correct if statement for color
* move config.h to main makefile, updates preonic, atomic
* format update, all keyboards targets
* makefile optional for build all target, alps and arrow_pad updated
* alps updated
* make planck default, trying out travis recipe for all-keyboards
* all-keymaps target, different travis recipe
* updates alps64
* updates keyboards to new format
* updates clue* projects
* all projects updated, specialise EZ .hex, let .hex through
* updates travis
* automatically find root, keyboard, keymap
* silent echo, cleaned-up mass make output
* updates all keyboards' .hex files except EZ
* Rename Bantam44.c to bantam44.c
* Rename Bantam44.h to bantam44.h
* nananana
* adds six key keyboard
* does same to ez as rest
* updates send_string example
* brings ergodox_ez up to date
* updates template/new project script
* adds sixkeyboard
* adds readme for sixkeyboard
* adds sixkeyboard to travis
* filenames, gitignore mess
* define clock prescaler stuff manually
* make quick, size test example
* documentation and dfu-no-build
* clean trailing ws in Vagrantfile and util/avr_setup.sh
* replace triple quotes with heredoc.
Ruby doesn't have triple quotes; that's a Python thing. This was just being
parsed as multiple strings concatenated.
* add docker support to Vagrantfile
* make wants to find dfu-programmer in vagrant guest
* Created arrow pad, a QMK based numpad designed for heavy text editing
* Enabled backlighting, numlock indicator, and forced nkro for arrowpad
* WIP Arrowpad 21
* WIP Arrowpad 21
* Combined Arrow Pad 21 and 24
* Combined Arrow Pad 21 and 24
* Removed 21 folder
The documentation for ugfx gEventWait wait is wrong and the
function takes the time in milliseconds, instead of system ticks.
This caused the the thread to sleep way too long. It also caused
somewhat random sleeping behaviour as the MS2ST function overflows
at around 43 seconds sleep.
The event source is also now initialized correctly, so that the
thread actually can be woken up by events.
https://support.apple.com/en-us/HT201236 says that ⌃⌘⏏ will quit all apps and then restart your Mac; ⌃⌘-power will shut things down in an…ungraceful fashion.
I reboot into Windows fairly frequently; I'd rather have the nice behavior at my fingertips, not the rude one.
* Autodetect teensy-loader-cli over teensy_loader_cli.
Some distributions (e.g. Arch Linux, Guix) install teensy_loader_cli
as teensy-loader-cli. Use this one if it is installed.
* Update ergodox_ez/readme.md
- Mention Linux distris providing teensy-loader-cli
- Mention `make teensy ...`
Moved the layer toggles to be in more comfortable locations for my typing. Also expanded the use of the media layer (now called APP) and enhanced the text navigation on the control layer
* Don't save the ctags file in the repo.
* Initial support for the KC60 board. Only 5x5 working so far.
* Rename because this isn't the same KC60 as others.
* Add in some generic layout.
Pins seem to be in the right order except the 6th column spews
gibberish.
* Don't need this for now.
* Move this to some other folder.
* Trying again to start over.
* Don't need to start over because I figured out why the 'broken' stuff wasn't working.
* Attempt to enable backlighting. It's on on pin B7 like other boards.
* Fix last port changes and fix LED control in keymap.
* Trying some other LED code.
* Bootloader needs to be bigger. Disabling backlight for now.
* Simplify LED code while I try to figure it out.
* Turn back on backlighting.
* Backlighting works now. Just need to get levels or breathing working.
* Trying to allow for turning off the LEDs before I get to brightness levels.
* The missing link: need to run the init_ports function for LEDs to work properly.
* Removing breathing stuff since it bricks the board.
* Clean up default layer.
* Cleanup keymap, KC60 doesn't support a 5th right bottom-row button.
This is a squashed up version of the layout I have been working on for
the past month or so. Based on Dvorak, with a lot of unconventional
stuff thrown in for good measures.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
* Updated personal layouts
* tweaked personal
* Nightly - Audio Cleanup
Refactored the LUTs. Abstracted some of the registers out of audio to
use more functional names. Split audio into audio and audio_pwm. WIP
* nightly - collapsed code
* Added check for note playing to LEDs
* Usability tweaks
* TWEAE
* nightly
added extra kcs to keymap common
* turned on Plank audio
* Added backlight breathing to atomic
* reverted accidental merge
* Added music and audio toggles to Quantum.c
* Redid the audio callbacks
* Adjusted default planck layout to use the user tone naming
* tabs to spaces
* Rewrote the ALL recipe to allow for faster parallel make
* tabs to spaces
* Renamed custom event functions to be 'startup_user' and 'shutdown_user'. Also moved the prototypes around.
* Tweaked pvc atomic layout to work with the pvc planck.
* updates midi scale calling
* Unicode
to have unicode input you need to:
- set your OS input method to UNICODE if needed
- enable unicode in your makefile
- copy the action_function from
keyboard/planck/keymaps/unicode/unicode.c to your keymap.c
set the target OS method in your keymap.c: void matrix_init_user() {
set_unicode_mode(UC_OSX); } you can then switch when you want with:
set_unicode_mode(UC_OSX); set_unicode_mode(UC_LNX);
set_unicode_mode(UC_WIN);
put some unicode codes in your keymap like so: UC(0x0061)
I did change the bit mask in quantum/keymap_common.c and .h
I’m afraid we will need uint32 to get a total support for all unicode
tables or relocate the handler as @mbarkhau did.
* rearranges keycode values, hooks-up unicode
* removes extra lalt ref
* adds unicode shortcuts and example
* Updated personal layouts
* tweaked personal
* Nightly - Audio Cleanup
Refactored the LUTs. Abstracted some of the registers out of audio to
use more functional names. Split audio into audio and audio_pwm. WIP
* nightly - collapsed code
* Added check for note playing to LEDs
* Usability tweaks
* TWEAE
* nightly
added extra kcs to keymap common
* turned on Plank audio
* Added backlight breathing to atomic
* reverted accidental merge
* Added music and audio toggles to Quantum.c
* Redid the audio callbacks
* music/audio_on_user
* implements leader key for planck experimental
* allows override of leader timeout
* adds ability to use the leader key in seq
* fixes leader keycode
* adds chording prototype
* fixes keycode detection
* moves music mode to quantum.c
* disables chording by default
* adds music sequencer functionality
* implements audio/music functions in quantum.c
* splits up process_action to allow independent processing of actions
* moves midi stuff to quantum.c
* adds additional scales for midi
* implements leader key for planck experimental
* allows override of leader timeout
* adds ability to use the leader key in seq
* fixes leader keycode
* adds chording prototype
* fixes keycode detection
* moves music mode to quantum.c
* disables chording by default
* adds music sequencer functionality
* implements audio/music functions in quantum.c
* splits up process_action to allow independent processing of actions
* merging?
* [planck] toggle plover output in app when toggling plover layer on keyboard
* [planck] moved plover toggle to separate key
* [planck] renamed toggle button
After using the layout a while I learn that the - and = positions should be
swapped since I keep typing = when I intend to type -.
I also, removed the only macro from the top left on the right hand to put the
power button there and since I never use the arrow keys on the separated groups
of keys, I added 4 macros there to get a feel for it.
Some options I defined on the config.h file don't make much sense to other
keymaps so I revert the global config.h and add those options on the keymap
custom one.
Instead of having a key on the left side for one layer and a key on the right
side for the other layer, I put two dedicated layers on each side to get to the
proper layers.
This keymap was created to have a feel keys on a different place and to have as
fewer layers as possible.
Currently I have only 2 extra layers and only one of them is really required to
have all possible keys available.
Check out the README.md file for more information.
* Updated personal layouts
* tweaked personal
* Nightly - Audio Cleanup
Refactored the LUTs. Abstracted some of the registers out of audio to
use more functional names. Split audio into audio and audio_pwm. WIP
* nightly - collapsed code
* Added check for note playing to LEDs
* Usability tweaks
* TWEAE
* nightly
added extra kcs to keymap common
* turned on Plank audio
* Added backlight breathing to atomic
* reverted accidental merge
* adds backlight pulse to planck
This commit is mostly a cherry-pick from `ahtn` at
https://github.com/tmk/tmk_keyboard/pull/255.
These are the changes:
* Adds ACTION_LAYER_ONESHOT
* Adds ONESHOT_TAP_TOGGLE
* Mentions sticky keys in the docs on oneshot.
* Updated personal layouts
* tweaked personal
* Nightly - Audio Cleanup
Refactored the LUTs. Abstracted some of the registers out of audio to
use more functional names. Split audio into audio and audio_pwm. WIP
* nightly - collapsed code
* Added check for note playing to LEDs
- layer modifiers in the thumb clusters, Alt-F1 - Alt-F4 should now be easier to type
- new Alt and Ctrl keys in the bottom row are more easily reachable with thumbs than the little thumb cluster keys, and feel more like traditional keyboards
- thumb backspace wasn't great due to lower precision and repeat rate than index fingers
- on mod keys, register LGUI, LSFT etc. as normal mods
instead of weak mods:
- they won't be cleared by layer switching
- LSFT(KC_LGUI) will now have the same behavior as LGUI(KC_LSFT)
Having "true" modifiers is more reliable and practical.
- moved APP in place of HOME
- moved HOME in place of LSFT on left thumb
- moved END in place of RSFT on right thumb (Ctrl+End with single hand!)
- removed ALT_T from KC_ESC
- all characters available directly in CSA
- more explicit names for macros that switch accross CSA layers
- use macros to implement the shifts next to the spaces
- implement easy way to define and send unicode characters on Windows
- define 3 characters not available in CSA:
- en dash: –
- em dash: —
- ellipsis: …
- implemented the most useful characters:
- all French characters + €
- common programmer characters
- other keys implemented as KC_NO to avoid mistyping a character
from a lower layer
- AltGr+Shift not supported (yet)
Initial implementation of the BÉPO layout
for use with the Canadian Multilingual Standard layout
(a.k.a. CSA / ACNOR layout) on the OS-side.
- support all bépo characters from the default and shifted layers
No more SFT_T:
- moved ] (bépo W) below Tab
- moved - (bépo =) in place of ] (top right)
- removed SFT_T from ' (bépo M)
- moved \ (bépo Ç) in place of = (bépo %)
- moved = (bépo %) in place of - (bépo =)
1. If you have ever installed WinAVR, uninstall it.
2. Install [MHV AVR Tools](https://infernoembedded.com/sites/default/files/project/MHV_AVR_Tools_20131101.exe). Disable smatch, but **be sure to leave the option to add the tools to the PATH checked**.
3. Install [MinGW](https://sourceforge.net/projects/mingw/files/Installer/mingw-get-setup.exe/download). During installation, uncheck the option to install a graphical user interface. **DO NOT change the default installation folder.** The scripts depend on the default location.
4. Clone this repository. [This link will download it as a zip file, which you'll need to extract.](https://github.com/jackhumbert/qmk_firmware/archive/master.zip) Open the extracted folder in Windows Explorer.
5. Right-click on the 1-setup-path-win batch script, select "Run as administrator", and accept the User Account Control prompt. Press the spacebar to dismiss the success message in the command prompt that pops up.
6. Right-click on the 2-setup-environment-win batch script, select "Run as administrator", and accept the User Account Control prompt. This part may take a couple of minutes, and you'll need to approve a driver installation, but once it finishes, your environment is complete!
7. Future build commands should be run from the standard Windows command prompt, which you can find by searching for "command prompt" from the start menu or start screen. Ignore the "MHV AVR Shell".
### Mac
If you're using [homebrew,](http://brew.sh/) you can use the following commands:
brew tap osx-cross/avr
brew install avr-libc
brew install dfu-programmer
This is the recommended method. If you don't have homebrew, [install it!](http://brew.sh/) It's very much worth it for anyone who works in the command line.
You can also try these instructions:
1. Install Xcode from the App Store.
2. Install the Command Line Tools from `Xcode->Preferences->Downloads`.
3. Install [DFU-Programmer][dfu-prog].
### Linux
Install AVR GCC, AVR libc, and dfu-progammer with your favorite package manager.
If you have any problems building the firmware, you can try using a tool called Vagrant. It will set up a virtual computer with a known configuration that's ready-to-go for firmware building. OLKB does NOT host the files for this virtual computer. Details on how to set up Vagrant are in the [VAGRANT_GUIDE file](VAGRANT_GUIDE.md).
## Verify Your Installation
1. If you haven't already, obtain this repository ([https://github.com/jackhumbert/qmk_firmware](https://github.com/jackhumbert/qmk_firmware)). You can either download it as a zip file and extract it, or clone it using the command line tool git or the Github Desktop application.
2. Open up a terminal or command prompt and navigate to the qmk_firmware folder using the `cd` command. The command prompt will typically open to your home directory. If, for example, you cloned the repository to your Documents folder, then you would type `cd Documents/qmk_firmware`. If you extracted the file from a zip, then it may be named `qmk_firmware-master` instead.
3. To confirm that you're in the correct location, you can display the contents of your current folder using the `dir` command on Windows, or the `ls` command on Linux or Mac. You should see several files, including `README.md` and a `quantum` folder. From here, you need to navigate to the appropriate folder under `keyboard/`. For example, if you're building for a Planck, run `cd keyboard/planck`.
4. Once you're in the correct keyboard-specific folder, run the `make` command. This should output a lot of information about the build process.
## Customizing, Building, and Deploying Your Firmware
Note: Some keyboard folders have non-standard organizations, and may not even support specifying alternate keymaps. Until these get reorganized, you will need to edit their default keymaps directly.
1. Running the `make` command from your keyboard's folder will generate a .hex file based on the default keymap. All keymaps for a particular keyboard live in the `keymaps` folder in that keyboard's folder. To create your own keymap, copy `keymaps/default/keymap.c` to the `keymaps` folder, and rename it with your name, for example jack.c. Or, if you don't care about the ability to share your keymap with the community via GitHub, you can just modify the default keymap itself. Details on how to program keymap files can be found in other guides.
2. To build a keymap other than the default, type `KEYMAP=<name>` after `make`. So if I've named my keymap jack.c, the full command would be `make KEYMAP=jack`.
3. How you deploy the firmware will depend on whether you are using a PCB or a Teensy. In both cases, you'll need to put the keyboard in bootloader mode, either by pressing a button on the PCB/Teensy or pressing the key with the `RESET` keycode. Then, if you're using a PCB, just run `make KEYMAP=<name> dfu` to both build and deploy the firmware. If you're using a Teensy, you'll probably need to take the <keyboardname>.hex file that make produces in the keyboard's folder, and deploy it using the [Teensy Loader.](https://www.pjrc.com/teensy/loader.html)
## Helpful Tips
1. On Linux or OS X, you can run `sleep 5; make KEYMAP=<name> dfu` to delay building/deploying the firmware until for 5 seconds, giving you a chance to put the firmware into bootloader mode. You can change the 5 to any number of seconds.
## Troubleshooting
1. Try running `make clean` if the make command fails.
QMK strives to be an inclusive and tolerant community. We welcome participation from anyone regardless of age, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, political belief, race, religion, or sexual identity and orientation.
> “A gentle word turns away wrath, but a harsh word stirs up anger.”
Our users, contributors, and collaborators are expected to treat each other with respect, to assume good intentions, and to gently correct, where possible, rather than react with escalation. Some examples of behavior we will not tolerate include, but is not limited to:
* The use of sexualized language or imagery
* Unwelcome advances, sexual or otherwise
* Insults or derogatory comments, or personal or political attacks
* Publishing others’ private information without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
If someone is violating this Code of Conduct you may email hello@qmk.fm to bring your concern to the Members. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident.
* Wire (strained for wiring to the Teensy, anything for the rows/columns)
* Soldering iron set at 600ºF or 315ºC (if temperature-controlled)
* Resin-cored solder (leaded or lead-free)
* Adequate ventilation/a fan
* Tweezers (optional)
* Wire cutters/snippers
## How the matrix works (why we need diodes)
The microcontroller (in this case, the Teensy 2.0) will be setup up via the firmware to send a logical 1 to the columns, one at a time, and read from the rows, all at once - this process is called matrix scanning. The matrix is a bunch of open switches that, by default, don't allow any current to pass through - the firmware will read this as no keys being pressed. As soon as you press one key down, the logical 1 that was coming from the column the keyswitch is attached to gets passed through the switch and to the corresponding row - check out the following 2x2 example:
Column 0 being scanned Column 1 being scanned
x x
col0 col1 col0 col1
| | | |
row0 ---(key0)---(key1) row0 ---(key0)---(key1)
| | | |
row1 ---(key2)---(key3) row1 ---(key2)---(key3)
The `x` represents that the column/row associated has a value of 1, or is HIGH. Here, we see that no keys are being pressed, so no rows get an `x`. For one keyswitch, keep in mind that one side of the contacts is connected to its row, and the other, its column.
When we press `key0`, `col0` gets connected to `row0`, so the values that the firmware receives for that row is `0b01` (the `0b` here means that this is a bit value, meaning all of the following digits are bits - 0 or 1 - and represent the keys in that column). We'll use this notation to show when a keyswitch has been pressed, to show that the column and row are being connected:
Column 0 being scanned Column 1 being scanned
x x
col0 col1 col0 col1
| | | |
x row0 ---(-+-0)---(key1) row0 ---(-+-0)---(key1)
| | | |
row1 ---(key2)---(key3) row1 ---(key2)---(key3)
We can now see that `row0` has an `x`, so has the value of 1. As a whole, the data the firmware receives when `key0` is pressed is
col0: 0b01
col1: 0b00
│└row0
└row1
A problem arises when you start pressing more than one key at a time. Looking at our matrix again, it should become pretty obvious:
Column 0 being scanned Column 1 being scanned
x x
col0 col1 col0 col1
| | | |
x row0 ---(-+-0)---(-+-1) x row0 ---(-+-0)---(-+-1)
| | | |
x row1 ---(key2)---(-+-3) x row1 ---(key2)---(-+-3)
Remember that this ^ is still connected to row1
The data we get from that is:
col0: 0b11
col1: 0b11
│└row0
└row1
Which isn't accurate, since we only have 3 keys pressed down, not all 4. This behavior is called ghosting, and only happens in odd scenarios like this, but can be much more common on a bigger keyboard. The way we can get around this is by placing a diode after the keyswitch, but before it connects to its row. A diode only allows current to pass through one way, which will protect our other columns/rows from being activated in the previous example. We'll represent a dioded matrix like this;
Column 0 being scanned Column 1 being scanned
x x
col0 col1 col0 col1
│ │ | │
(key0) (key1) (key0) (key1)
! │ ! │ ! | ! │
row0 ─────┴────────┘ │ row0 ─────┴────────┘ │
│ │ | │
(key2) (key3) (key2) (key3)
! ! ! !
row1 ─────┴────────┘ row1 ─────┴────────┘
In practical applications, the black line of the diode will be placed facing the row, and away from the keyswitch - the `!` in this case is the diode, where the gap represents the black line. A good way to remember this is to think of this symbol: `>|`
Now when we press the three keys, invoking what would be a ghosting scenario:
Column 0 being scanned Column 1 being scanned
x x
col0 col1 col0 col1
│ │ │ │
(┌─┤0) (┌─┤1) (┌─┤0) (┌─┤1)
! │ ! │ ! │ ! │
x row0 ─────┴────────┘ │ x row0 ─────┴────────┘ │
│ │ │ │
(key2) (┌─┘3) (key2) (┌─┘3)
! ! ! !
row1 ─────┴────────┘ x row1 ─────┴────────┘
Things act as they should! Which will get us the following data:
col0: 0b01
col1: 0b11
│└row0
└row1
The firmware can then use this correct data to detect what it should do, and eventually, what signals it needs to send to the OS.
## The actual hand-wiring
### Getting things in place
When starting this, you should have all of your stabilisers and keyswitches already installed (and optionally keycaps). If you're using a Cherry-type stabiliser (plate-mounted only, obviously), you'll need to install that before your keyswitches. If you're using Costar ones, you can installed them afterwards.
To make things easier on yourself, make sure all of the keyswitches are oriented the same way (if they can be - not all layouts support this). Despite this, it's important to remember that the contacts on the keyswitches are completely symmetrical. We'll be using the keyswitch's left side contact for wiring the rows, and the right side one for wiring the columns.
Get your soldering iron heated-up and collect the rest of the materials from the part list at the beginning of the guide. Place your keyboard so that the bottoms of the keyswitches are accessible - it may be a good idea to place it on a cloth to protect your keyswitches/keycaps.
Before continuing, plan out where you're going to place your Teensy. If you're working with a board that has a large (6.25u) spacebar, it may be a good idea to place it in-between switches against the plate. Otherwise, you may want to trim some of the leads on the keyswitches where you plan on putting it - this will make it a little harder to solder the wire/diodes, but give you more room to place the Teensy.
### Preparing the diodes
It's a little easier to solder the diodes in place if you bend them at a 90º angle immediately after the black line - this will help to make sure you put them on the right way (direction matters), and in the correct position. The diodes will look like this when bent (with longer leads):
┌─────┬─┐
───┤ │ ├─┐
└─────┴─┘ │
│
We'll be using the long lead at the bent end to connect it to the elbow (bent part) of the next diode, creating the row.
### Soldering the diodes
Starting at the top-left switch, place the diode (with tweezers if you have them) on the switch so that the diode itself is vertically aligned, and the black line is facing toward you. The straight end of the diode should be touching the left contact on the switch, and the bent end should be facing to the right and resting on the switch there, like this:
│o
┌┴┐ o
│ │ O
├─┤
└┬┘
└─────────────
Letting the diode rest, grab your solder, and touch both it and the soldering iron to the left contact at the same time - the rosin in the solder should make it easy for the solder to flow over both the diode and the keyswitch contact. The diode may move a little, and if it does, carefully position it back it place by grabbing the bent end of the diode - the other end will become hot very quickly. If you find that it's moving too much, using needle-nose pliers of some sort may help to keep the diode still when soldering.
The smoke that the rosin releases is harmful, so be careful not to breath it or get it in your eyes/face.
After soldering things in place, it may be helpful to blow on the joint to push the smoke away from your face, and cool the solder quicker. You should see the solder develop a matte (not shiney) surface as it solidifies. Keep in mind that it will still be very hot afterwards, and will take a couple minutes to be cool to touch. Blow on it will accelerate this process.
When the first diode is complete, the next one will need to be soldered to both the keyswitch, and the previous diode at the new elbow. That will look something like this:
│o │o
┌┴┐ o ┌┴┐ o
│ │ O │ │ O
├─┤ ├─┤
└┬┘ └┬┘
└────────────────┴─────────────
After completing a row, use the wire cutters to trim the excess wire from the tops of the diodes, and from the right side on the final switch. This process will need to completed for each row you have.
When all of the diodes are completely soldered, it's a good idea to quickly inspect each one to ensure that your solder joints are solid and sturdy - repairing things after this is possible, but more difficult.
### Soldering the columns
You'll have some options in the next process - it's a good idea to insulate the column wires (since the diodes aren't), but if you're careful enough, you can use exposed wires for the columns - it's not recommended, though. If you're using single-cored wire, stripping the plastic off of the whole wire and feeding it back on is probably the best option, but can be difficult depending on the size and materials. You'll want to leave parts of the wire exposed where you're going to be solder it onto the keyswitch.
If you're using stranded wire, it's probably easiest to just use a lot of small wires to connect each keyswitch along the column. It's possible to use one and melt through the insulation, but this isn't recommended, will produce even more harmful fumes, and can ruin your soldering iron.
Before beginning to solder, it helps to have your wire pre-bent (if using single-cored), or at least have an idea of how you're going to route the column (especially if you're making a staggered board). Where you go in particular doesn't matter too much, as we'll be basing our keymap definitions on how it was wired - just make sure every key in a particular row is in a unique column, and that they're in order from left to right.
If you're not using any insulation, you can try to keep the column wires elevated, and solder them near the tips of the keyswitch contacts - if the wires are sturdy enough, they won't short out to the row wiring an diodes.
### Wiring things to the Teensy
Now that the matrix itself is complete, it's time to connect what you've done to the Teensy. You'll be needing the number of pins equal to your number of columns + your number of rows. There are some pins on the Teensy that are special, like D6 (the LED on the chip), or some of the UART, SPI, I2C, or PWM channels, but only avoid those if you're planning something in addition to a keyboard. If you're unsure about wanting to add something later, you should have enough pins in total to avoid a couple.
The pins you'll absolutely have to avoid are: GND, VCC, AREF, and RST - all the others are usable and accessible in the firmware.
Place the Teensy where you plan to put it - you'll have to cut wires to length in the next step, and you'll want to make sure they reach.
Starting with the first column on the right side, measure out how much wire you'll need to connect it to the first pin on the Teensy - it helps to pick a side that you'll be able to work down, to keep the wires from overlapping too much. It may help to leave a little bit of slack so things aren't too tight. Cut the piece of wire, and solder it to the Teensy, and then the column - you can solder it anywhere along the column, but it may be easiest at the keyswitch. Just be sure the wire doesn't separate from the keyswitch when soldering.
As you move from column to column, it'll be helpful to write the locations of the pins down. We'll use this data to setup the matrix in the future.
When you're done with the columns, start with the rows in the same process, from top to bottom, and write them all down. Again, you can solder anywhere along the row, as long as it's after the diode - soldering before the diode (on the keyswitch side) will cause that row not to work.
As you move along, be sure that the Teensy is staying in place - recutting and soldering the wires is a pain!
### Getting some basic firmware set-up
From here, you should have a working keyboard with the correct firmware. Before we attach the Teensy permanently to the keyboard, let's quickly get some firmware loaded onto the Teensy so we can test each keyswitch.
To start out, download [the firmware](https://github.com/jackhumbert/qmk_firmware/) - we'll be using my (Jack's) fork of TMK called QMK/Quantum. We'll be doing a lot from the Terminal/command prompt, so get that open, along with a decent text editor like [Sublime Text](http://www.sublimetext.com/).
The first thing we're going to do is create a new project using the script in the root directory of the firmware. In your terminal, run this command with `<project_name>` replaced by the name of your project - it'll need to be different from any other project in the `keyboard/` folder:
./new_project.sh <project_name>
You'll want to navigate to the `keyboard/<project_name>/` folder by typing, like the print-out from the script specifies:
cd keyboard/<project_name>
#### config.h
The first thing we're going to want to modify is the `config.h` file. On line 32 and 33, you'll see `MATRIX_ROWS` and `MATRIX_COLS` - set both these variables to however many rows and columns you have on your keyboard.
On line 38 and 39 you'll see the `COLS` and `ROWS` definitions - this is where you'll enter the pins you used, in order (left-to-right when looking at the top of the keyboard, but right-to-left when looking at the bottom).
There are some other variables that you'll be able to modify (lines 23-29), but it's not necessary to do that now (or ever, really).
#### \<project_name\>.h
The next file you'll want to look at is `<project_name>.h`. You're going to want to rewrite the `KEYMAP` definition - the format and syntax here is extremely important, so pay attention to how things are setup. The first half of the definition are considered the arguments - this is the format that you'll be following in your keymap later on, so you'll want to have as many k*xy* variables here as you do keys. The second half is the part that the firmware actually looks at, and will contain gaps depending on how you wired your matrix.
We'll dive into how this will work with the following example. Say we have a keyboard like this:
┌───┬───┬───┐
│ │ │ │
├───┴─┬─┴───┤
│ │ │
└─────┴─────┘
This can be described by saying the top row is 3 1u keys, and the bottom row is 2 1.5u keys. The difference between the two rows is important, because the bottom row has an unused column spot (3 v 2). Let's say that this is how we wired the columns:
┌───┬───┬───┐
│ ┋ │ ┋ │ ┋ │
├─┋─┴─┬─┴─┋─┤
│ ┋ │ ┋ │
└─────┴─────┘
The middle column is unused on the bottom row in this example. Our `KEYMAP` definition would look like this:
#define KEYMAP( \
k00, k01, k02, \
k10, k11, \
) \
{ \
{ k00, k01, k02 }, \
{ k10, KC_NO, k11 }, \
}
Notice how the top half is spaced to resemble our physical layout - this helps us understand which keys are associated with which columns. The bottom half uses the keycode `KC_NO` where there is no keyswitch wired in. It's easiest to keep the bottom half aligned in a grid to help us make sense of how the firmware actually sees the wiring.
Let's say that instead, we wired our keyboard like this (a fair thing to do):
┌───┬───┬───┐
│ ┋ │ ┋│ ┋ │
├─┋─┴─┬┋┴───┤
│ ┋ │┋ │
└─────┴─────┘
This would require our `KEYMAP` definition to look like this:
#define KEYMAP( \
k00, k01, k02, \
k10, k11, \
) \
{ \
{ k00, k01, k02 }, \
{ k10, k11, KC_NO }, \
}
Notice how the `k11` and `KC_NO` switched places to represent the wiring, and the unused final column on the bottom row. Sometimes it'll make more sense to put a keyswitch on a particular column, but in the end, it won't matter, as long as all of them are accounted for. You can use this process to write out the `KEYMAP` for your entire keyboard - be sure to remember that your keyboard is actually backwards when looking at the underside of it.
#### keymaps/default.c
This is the actual keymap for your keyboard, and the main place you'll make changes as you perfect your layout. `default.c` is the file that gets pull by default when typing `make`, but you can make other files as well, and specify them by typing `make KEYMAP=<variant>`, which will pull `keymaps/<variant>.c`.
The basis of a keymap is its layers - by default, layer 0 is active. You can activate other layers, the highest of which will be referenced first. Let's start with our base layer.
Using our previous example, let's say we want to create the following layout:
┌───┬───┬───┐
│ A │ 1 │ H │
├───┴─┬─┴───┤
│ TAB │ SPC │
└─────┴─────┘
This can be accomplished by using the following `keymaps` definition:
Note that the layout of the keycodes is similar to the physical layout of our keyboard - this make it much easier to see what's going on. A lot of the keycodes should be fairly obvious, but for a full list of them, check out [tmk_code/doc/keycode.txt](https://github.com/jackhumbert/qmk_firmware/blob/master/tmk_core/doc/keycode.txt) - there are also a lot of aliases to condense your keymap file.
It's also important to use the `KEYMAP` function we defined earlier - this is what allows the firmware to associate our intended readable keymap with the actual wiring.
#### Compiling your firmware
After you've written out your entire keymap, you're ready to get the firmware compiled and onto your Teensy. Before compiling, you'll need to get your [development environment set-up](https://github.com/jackhumbert/qmk_firmware/blob/master/keyboard/planck/PCB_GUIDE.md#setting-up-the-environment) - you can skip the dfu-programmer instructions, but you'll need to download and install the [Teensy Loader](https://www.pjrc.com/teensy/loader.html) to get the firmware on your Teensy.
Once everything is installed, running `make` in the terminal should get you some output, and eventually a `<project_name>.hex` file in that folder. If you're having trouble with this step, see the end of the guide for the trouble-shooting section.
Once you have your `<project_name>.hex` file, open up the Teensy loader application, and click the file icon. From here, navigate to your `QMK/keyboard/<project_name>/` folder, and select the `<project_name>.hex` file. Plug in your keyboard and press the button on the Teensy - you should see the LED on the device turn off once you do. The Teensy Loader app will change a little, and the buttons should be clickable - click the download button (down arrow), and then the reset button (right arrow), and your keyboard should be ready to go!
#### Testing your firmware
Carefully flip your keyboard over, open up a new text document, and try typing - you should get the characters that you put into your keymap. Test each key, and note the ones that aren't working. Here's a quick trouble-shooting guide for non-working keys:
0. Flip the keyboard back over and short the keyswitch's contacts with a piece wire - this will eliminate the possibility of the keyswitch being bad and needing to be replaced.
1. Check the solder points on the keyswitch - these need to be plump and whole. If you touch it with a moderate amount of force and it comes apart, it's not strong enough.
2. Check the solder joints on the diode - if the diode is loose, part of your row may register, while the other may not.
3. Check the solder joints on the columns - if your column wiring is loose, part or all of the column may not work.
4. Check the solder joints on both sides of the wires going to/from the Teensy - the wires need to be fully soldered and connect to both sides.
5. Check the <project_name>.h file for errors and incorrectly placed `KC_NO`s - if you're unsure where they should be, instead duplicate a k*xy* variable.
6. Check to make sure you actually compiled the firmware and flashed the Teensy correctly. Unless you got error messages in the terminal, or a pop-up during flashing, you probably did everything correctly.
If you've done all of these things, keep in mind that sometimes you might have had multiple things affecting the keyswitch, so it doesn't hurt to test the keyswitch by shorting it out at the end.
#### Securing the Teensy, finishing your hardware, getting fancier firmware
Now that you have a working board, it's time to get things in their permanent positions. I've often used liberal amounts of hot glue to secure and insulate things, so if that's your style, start spreading that stuff like butter. Otherwise, double-sided tape is always an elegant solution, and electrical tape is a distant second. Due to the nature of these builds, a lot of this part is up to you and how you planned (or didn't plan) things out.
There are a lot of possibilities inside the firmware - check out the [README](https://github.com/jackhumbert/qmk_firmware/blob/master/README.md) for a full feature list, and dive into the different project (Planck, Ergodox EZ, etc) to see how people use all of them. You can always stop by [the OLKB subreddit for help!](http://reddit.com/r/olkb)
This is a keyboard firmware based on the [tmk_keyboard firmware](http://github.com/tmk/tmk_keyboard) with some useful features for Atmel AVR controllers, and more specifically, the [OLKB product line](http://olkb.co), the [ErgoDox EZ](http://www.ergodox-ez.com) keyboard, and the [Clueboard product line](http://clueboard.co/).
QMK is developed and maintained by Jack Humbert of OLKB with contributions from the community, and of course, TMK.
This documentation is edited and maintained by Erez Zukerman of ErgoDox EZ. If you spot any typos or inaccuracies, please [open an issue](https://github.com/jackhumbert/qmk_firmware/issues/new).
The OLKB product firmwares are maintained by Jack, the Ergodox EZ by Erez, and the Clueboard by [Zach White](https://github.com/skullydazed).
## Important background info: TMK documentation
The documentation below explains QMK customizations and elaborates on some of the more useful features of TMK. To understand the base firmware, and especially what *layers* are and how they work, please see [TMK_README.md](/TMK_README.md).
## Getting started
* [BUILD_GUIDE.md](BUILD_GUIDE.md) contains instructions to set up a build environment, build the firmware, and deploy it to a keyboard. Once your build environment has been set up, all `make` commands to actually build the firmware must be run from a folder in `keyboard/`.
* If you're looking to customize a keyboard that currently runs QMK or TMK, find your keyboard's directory under `keyboard/` and run the make commands from there.
* If you're looking to apply this firmware to an entirely new hardware project (a new kind of keyboard), you can create your own Quantum-based project by using `./new_project.sh <project_name>`, which will create `/keyboard/<project_name>` with all the necessary components for a Quantum project.
### Makefile Options
You have access to a bunch of goodies! Check out the Makefile to enable/disable some of the features. Uncomment the `#` to enable them. Setting them to `no` does nothing and will only confuse future you.
*`ALL_T(kc)`-isHyper(allmods)whenheldand*kc*whentapped.ToreadmoreaboutwhatyoucandowithaHyperkey,see [this blog post by Brett Terpstra](http://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/)
constmacro_t*action_get_macro(keyrecord_t*record,uint8_tid,uint8_topt)// this is the function signature -- just copy/paste it into your keymap file as it is.
{
switch(id){
case0:// this would trigger when you hit a key mapped as M(0)
if(record->event.pressed){
returnMACRO(I(255),T(H),T(E),T(L),T(L),W(255),T(O),END);// this sends the string 'hello' when the macro executes
#### Example 2: Space Cadet Shift (making it easy to send opening and closing parentheses)
Inthe [Modern Space Cadet Keyboard](http://stevelosh.com/blog/2012/10/a-modern-space-cadet/#shift-parentheses),oneofcoolerfeaturesistheShiftParentheses.ToquoteSteveLosh:
> When held while pressing other keys, act like Shift.
> When pressed and released on their own, type an opening or closing parenthesis (left and right shift respectively).
If you use Dvorak, use `keymap_dvorak.h` instead of `keymap_colemak.h` for this line. After including this line, you will get access to:
*`CM_*` for all of the Colemak-equivalent characters
*`DV_*` for all of the Dvorak-equivalent characters
These implementations assume you're using Colemak or Dvorak on your OS, not on your keyboard - this is referred to as a software-implemented layout. If your computer is in Qwerty and your keymap is in Colemak or Dvorak, this is referred to as a firmware-implemented layout, and you won't need these features.
To give an example, if you're using software-implemented Colemak, and want to get an `F`, you would use `CM_F` - `KC_F` under these same circumstances would result in `T`.
## Additional language support
In `quantum/keymap_extras/`, you'll see various language files - these work the same way as the alternative layout ones do. Most are defined by their two letter country/language code followed by an underscore and a 4-letter abbreviation of its name. `FR_UGRV` which will result in a `ù` when using a software-implemented AZERTY layout. It's currently difficult to send such characters in just the firmware (but it's being worked on - see Unicode support).
## Unicode support
You can currently send 4 hex digits with your OS-specific modifier key (RALT for OSX with the "Unicode Hex Input" layout) - this is currently limited to supporting one OS at a time, and requires a recompile for switching. 8 digit hex codes are being worked on. The keycode function is `UC(n)`, where *n* is a 4 digit hexidecimal. Enable from the Makefile.
## Other firmware shortcut keycodes
*`RESET` - puts the MCU in DFU mode for flashing new firmware (with `make dfu`)
*`DEBUG` - the firmware into debug mode - you'll need hid_listen to see things
*`BL_ON` - turns the backlight on
*`BL_OFF` - turns the backlight off
*`BL_<n>` - sets the backlight to level *n*
*`BL_INC` - increments the backlight level by one
*`BL_DEC` - decrements the backlight level by one
*`BL_TOGG` - toggles the backlight
*`BL_STEP` - steps through the backlight levels
Enable the backlight from the Makefile.
## MIDI functionalty
This is still a WIP, but check out `quantum/keymap_midi.c` to see what's happening. Enable from the Makefile.
## Bluetooth functionality
This requires [some hardware changes](https://www.reddit.com/r/MechanicalKeyboards/comments/3psx0q/the_planck_keyboard_with_bluetooth_guide_and/?ref=search_posts), but can be enabled via the Makefile. The firmware will still output characters via USB, so be aware of this when charging via a computer. It would make sense to have a switch on the Bluefruit to turn it off at will.
## International Characters on Windows
[AutoHotkey](https://autohotkey.com) allows Windows users to create custom hotkeys among others.
The method does not require Unicode support in the keyboard itself but depends instead of AutoHotkey running in the background.
First you need to select a modifier combination that is not in use by any of your programs.
CtrlAltWin is not used very widely and should therefore be perfect for this.
There is a macro defined for a mod-tab combo `LCAG_T`.
Add this mod-tab combo to a key on your keyboard, e.g.: `LCAG_T(KC_TAB)`.
This makes the key behave like a tab key if pressed and released immediately but changes it to the modifier if used with another key.
In the default script of AutoHotkey you can define custom hotkeys.
<^<!<#a::Send, ä
<^<!<#<+a::Send, Ä
The hotkeys above are for the combination CtrlAltGui and CtrlAltGuiShift plus the letter a.
AutoHotkey inserts the Text right of `Send, ` when this combination is pressed.
## RGB Under Glow Mod
Here is a quick demo on Youtube (with NPKC KC60) (https://www.youtube.com/watch?v=VKrpPAHlisY).
For this mod, you need an unused pin wiring to DI of WS2812 strip. After wiring the VCC, GND, and DI, you can enable the underglow in your Makefile.
RGBLIGHT_ENABLE = yes
Please note that the underglow is not compatible with audio output. So you cannot enable both of them at the same time.
Please add the following options into your config.h, and set them up according your hardware configuration. These settings are for the F4 by default:
#define ws2812_PORTREG PORTF
#define ws2812_DDRREG DDRF
#define ws2812_pin PF4
#define RGBLED_NUM 14 // Number of LEDs
#define RGBLIGHT_HUE_STEP 10
#define RGBLIGHT_SAT_STEP 17
#define RGBLIGHT_VAL_STEP 17
You'll need to edit `PORTF`, `DDRF`, and `PF4` on the first three lines to the port/pin you have your LED(s) wired to, eg for B3 change things to:
#define ws2812_PORTREG PORTB
#define ws2812_DDRREG DDRB
#define ws2812_pin PB3
The firmware supports 5 different light effects, and the color (hue, saturation, brightness) can be customized in most effects. To control the underglow, you need to modify your keymap file to assign those functions to some keys/key combinations. For details, please check this keymap. `keyboard/planck/keymaps/yang/keymap.c`
Please note the USB port can only supply a limited amount of power to the keyboard (500mA by standard, however, modern computer and most usb hubs can provide 700+mA.). According to the data of NeoPixel from Adafruit, 30 WS2812 LEDs require a 5V 1A power supply, LEDs used in this mod should not more than 20.
## Safety Considerations
You probably don't want to "brick" your keyboard, making it impossible
to rewrite firmware onto it. Here are some of the parameters to show
what things are (and likely aren't) too risky.
- If a keyboard map does not include RESET, then, to get into DFU
mode, you will need to press the reset button on the PCB, which
requires unscrewing some bits.
- Messing with tmk_core / common files might make the keyboard
inoperable
- Too large a .hex file is trouble; `make dfu` will erase the block,
test the size (oops, wrong order!), which errors out, failing to
flash the keyboard
- DFU tools do /not/ allow you to write into the bootloader (unless
you throw in extra fruitsalad of options), so there is little risk
there.
- EEPROM has around a 100000 write cycle. You shouldn't rewrite the
firmware repeatedly and continually; that'll burn the EEPROM
**GPLv2** or later. Some protocol files are under **Modified BSD License**.
Third party libraries like LUFA, PJRC and V-USB have their own license respectively.
Build Firmware and Program Controller
-------------------------------------
See [doc/build.md](tmk_core/doc/build.md), or the README in the particular keyboard/* folder.
Change your keymap
------------------
See [doc/keymap.md](tmk_core/doc/keymap.md).
Magic Commands
--------------
To see help press `Magic` + `H`.
`Magic` key combination is `LShift` + `RShift` in many project, but `Power` key on ADB converter.
`Magic` keybind can be vary on each project, check `config.h` in project directory.
Following commands can be also executed with `Magic` + key. In console mode `Magic` keybind is not needed.
----- Command Help -----
c: enter console mode
d: toggle debug enable
x: toggle matrix debug
k: toggle keyboard debug
m: toggle mouse debug
v: print device version & info
t: print timer count
s: print status
e: print eeprom config
n: toggle NKRO
0/F10: switch to Layer0
1/F1: switch to Layer1
2/F2: switch to Layer2
3/F3: switch to Layer3
4/F4: switch to Layer4
PScr: power down/remote wake-up
Caps: Lock Keyboard(Child Proof)
Paus: jump to bootloader
Boot Magic Configuration - Virtual DIP Switch
---------------------------------------------
Boot Magic are executed during boot up time. Press Magic key below then plug in keyboard cable.
Note that you must use keys of **Layer 0** as Magic keys. These settings are stored in EEPROM so that retain your configure over power cycles.
To avoid configuring accidentally additive salt key `KC_SPACE` also needs to be pressed along with the following configuration keys. The salt key is configurable in `config.h`. See [tmk_core/common/bootmagic.h](tmk_core/common/bootmagic.h).
#### General
- Skip reading EEPROM to start with default configuration(`ESC`)
- Clear configuration stored in EEPROM to reset configuration(`Backspace`)
#### Bootloader
- Kick up Bootloader(`B`)
#### Debug
- Debug enable(`D`)
- Debug matrix enable(`D`+`X`)
- Debug keyboard enable(`D`+`K`)
- Debug mouse enable(`D`+`M`)
#### Keymap
- Swap Control and CapsLock(`Left Control`)
- Change CapsLock to Control(`Caps Lock`)
- Swap LeftAlt and Gui(`Left Alt`)
- Swap RightAlt and Gui(`Right Alt`)
- Disable Gui(`Left Gui`)
- Swap Grave and Escape(`Grave`)
- Swap BackSlash and BackSpace(`Back Slash`)
- Enable NKRO on boot(`N`)
#### Default Layer
- Set Default Layer to 0(`0`)
- Set Default Layer to 1(`1`)
- Set Default Layer to 2(`2`)
- Set Default Layer to 3(`3`)
- Set Default Layer to 4(`4`)
- Set Default Layer to 5(`5`)
- Set Default Layer to 6(`6`)
- Set Default Layer to 7(`7`)
Mechanical Locking support
--------------------------
This feature makes it possible for you to use mechanical locking switch for `CapsLock`, `NumLock`
or `ScrollLock`. To enable this feature define these macros in `config.h` and use `KC_LCAP`, `KC_LN
UM` or `KC_LSCR` in keymap for locking key instead of normal `KC_CAPS`, `KC_NLCK` or `KC_SLCK`. Res
ync option tries to keep switch state consistent with keyboard LED state.
#define LOCKING_SUPPORT_ENABLE
#define LOCKING_RESYNC_ENABLE
Start Your Own Project
-----------------------
**TBD**
Debugging
--------
Use PJRC's `hid_listen` to see debug messages. You can use the tool for debug even if firmware use LUFA stack.
You can use xprintf() to display debug info on `hid_listen`, see `tmk_core/common/xprintf.h`.
Files and Directories
-------------------
### Top
* tmk_core/ - core library
* keyboard/ - keyboard projects
* converter/ - protocol converter projects
* doc/ - documents
Coding Style
-------------
- Doesn't use Tab to indent, use 4-spaces instead.
Other Keyboard Firmware Projects
------------------
You can learn a lot about keyboard firmware from these. See [doc/other_projects.md](tmk_core/doc/other_projects.md).
This project includes a Vagrantfile that will allow you to build a new firmware for your keyboard very easily without major changes to your primary operating system. This also ensures that when you clone the project and perform a build, you have the exact same environment as anyone else using the Vagrantfile to build. This makes it much easier for people to help you troubleshoot any issues you encounter.
## Requirements
Using the Vagrantfile in this repository requires you have [Vagrant](http://www.vagrantup.com/) as well as [VirtualBox](https://www.virtualbox.org/) (or [VMware Workstation](https://www.vmware.com/products/workstation) and [Vagrant VMware plugin](http://www.vagrantup.com/vmware) but the (paid) VMware plugin requires a licensed copy of VMware Workstation/Fusion).
*COMPATIBILITY NOTICE* Certain versions of Virtualbox 5 appear to have an incompatibility with the Virtualbox extensions installed in the boxes in this Vagrantfile. If you encounter any issues with the /vagrant mount not succeeding, please upgrade your version of Virtualbox to at least 5.0.12.
Other than having Vagrant and Virtualbox installed and possibly a restart of your computer afterwards, you can simple run a 'vagrant up' anywhere inside the folder where you checked out this project and it will start a Linux virtual machine that contains all the tools required to build this project. There is a post Vagrant startup hint that will get you off on the right foot, otherwise you can also reference the build documentation below.
Build Firmware and Program Controller
-------------------------------------
See [doc/build.md](tmk_core/doc/build.md), or the README in the particular keyboard/* folder.
Change your keymap
------------------
See [doc/keymap.md](tmk_core/doc/keymap.md).
## Flashing the firmware
The "easy" way to flash the firmware is using a tool from your host OS like the Teensy programming app. [ErgoDox EZ](keyboard/ergodox_ez/readme.md) gives a great example.
If you want to program via the command line you can uncomment the ['modifyvm'] lines in the Vagrantfile to enable the USB passthrough into Linux and then program using the command line tools like dfu-util/dfu-programmer or you can install the Teensy CLI version.
Connect ADB pins to controller just by 3 lines(Vcc, GND, Data). By default Data line uses port PD0.
ADB female socket from the front:
,--_--.
/ o4 3o \ 1: DATA
| o2 1o | 2: Power SW
- === - 3: VCC
`-___-' 4: GND
This converter uses AVR's internal pull-up, but it seems to be too weak, in particular when you want to use a long or coiled cable. The external pull-up resistor(1K-10K Ohm) on Data is strongly recommended.(It is almost must!)
Define following macros for ADB connection in config.h if you use other than port PD0.
ADB_PORT, ADB_PIN, ADB_DDR, ADB_DATA_BIT
Build
-----
See doc/build.md. In short,
$ make clean
$ make
You can select keymap(ansi is default) like this:
$ make KEYMAP=[ansi|iso|hasu]
Keymap
------
You can change a keymap by editing code of keymap_[ansi|iso|hasu|yours].c.
How to define the keymap is probably obvious. You can find key symbols in common/keycode.h. And see doc/keymap.md for more detail.
Magic command
-------------
To get help press `h` holding Magic key. Magic key is `Power key`.
Locking CapsLock
----------------
Many of old ADB keyboards have mechanical push-lock switch for Capslock key and this converter supports the locking Capslock key by default. See README in top directory for more detail about this feature.
This firmware converts IBM 4704 keyboard protocol to USB HID.
Keyboard initialization process takes a few seconds at start up. During that you will hear buzzer from the keyboard. **You need to plug USB cable after hooking up your keyboard to the converter.**
Update
------
2015/09/07 Added keymap for Alps 102-key. Thanks, tai @ geekhack!
2015/05/05 Added keymaps for 107-key, 77-key and 50-key. Thanks, orihalcon @ geekhack!
2015/05/19 Fixed a protocol handling bug.
Supported Keyboard
------------------
### IBM capacitive switch models:
- 6019273 Model 100 50-key (grid layout) http://kishy.ca/?p=894
- 6019284 Model 200 62-key Alpha(60% layout) http://kishy.ca/?p=894
- 6019303 Model 300 77-key Expanded Alpha http://deskthority.net/photos-f62/ibm-6019303-t8502.html
- 6020218 Model 400 107-key Full key http://kishy.ca/?p=894
### Alps switch(vintage Green) models:
- 5954339 Japanese 102-key http://deskthority.net/post87127.html#p87127
- 6112883 Japanese 102-key http://geekhack.org/index.php?topic=52888.msg1194489#msg1194489
- 6112884 Japanese 102-key http://geekhack.org/index.php?topic=50437.msg1193047#msg1193047
- 6341739 Chinese 102-key http://geekhack.org/index.php?topic=52888.msg1176566#msg1176566
Connector
---------
Keyboard Plug from front:
DSUB-9
-------------
\ N 2 3 4 5 /
\ N N N N /
---------
2 GND
3 VCC 5V
4 DATA
5 CLOCK
N No connection/No pin.
Connection
----------
In case of using ATMega32U4(Teensy2.0):
1. Supply power with VCC and GND.
2. Connect CLOCK to PD1 and DATA to PD0. You can change pin with config.h.
3. Optionally you may need pull-up register. 1KOhm probably work.
Build Firmware
--------------
Just run `make`:
$ make
To select keymap:
$ make KEYMAP=[plain|...]
Keymap
------
Several version of keymap are available in advance but you are recommended to define your favorite layout yourself. To define your own keymap create file named `keymap_<name>.c` and see keymap document(you can find in top README.md) and existent keymap files.
Use `KEYMAP_ALPS102()` to define your keymap for Alps models.
This firmware converts the protocol of Apple Macintosh keyboard **M0110**, **M0110A** and **M0120** into USB. Target of this project is USB AVR controller like **ATmega32U2** and **ATmega32U4**. Using this converter you can revive these retro keyboards with modern computer.
Read README of top directory too.
Pictures of **M0110 + M0120** and **M0110A**.
- M0110A support was contributed by [skagon@github](https://github.com/skagon).
- M0120 also is supported. keys(+ * / and ,) on M0120 are recognized as cursor keys.
Update
------
- 2013/08: Change port for signals `PF` to `PD`
- 2013/09: Change port again, it uses inversely `PD0` for data and `PD1` for clock line now.
- 2014/06: Change keymaps
- 2015/03: Add support for "International"(ISO) keyboard(keymap_intl.c)
Building Hardware
-----------------
You need [TMK converter] or AVR dev board like PJRC [Teensy]. Port of the MCU `PD1` is assigned to `CLOCK` line and `PD0` to `DATA` by default, you can change pin configuration with editing `config.h`.
You may need pull-up resistors on signal lines(`CLOCK`, `DATA`) in particular when you have long or coiled cable. **1k-10k Ohm** will be OK for this purpose. In that case the converter may not read signal from keyboard correctly without pull-up resistors.
Building Firmware
-----------------
To compile firmware you need AVR GCC. You can edit *Makefile* and *config.h* to change compile options and pin configuration. Also `KEYMAP` option can be used to select keymap.
$ make -f Makefile.rev2 [KEYMAP={default|intl|spacefn|hasu}]
Use `Maefile.tmk_rev1` for TMK converter Rev.1, `Makefile.teensy` for Teensy instead.
Keymap
------
To create your own keymap copy existent keymap file to `keymap_name.c` and edit it.
Debug
-----
You can use [PJRC HID listen](http://www.pjrc.com/teensy/hid_listen.html) to see debug output. The converter has some functions for debug, press `<Magic>+H` simultaneously to get help.
- Magic combo: `Shift+Option+⌘` or `Shift+Option+Ctrl`(`Shift+Alt+Gui` or `Shift+Alt+Control`)
|Yello|--\-------- to computer via Mini-Din 5a Connector
|Orang|--/--------
|Red |-/
|Brown|/
+-----+
Black - Ground to outer metal part of Mini Din 5a connector (not used)
Green - Ground
Yellow - Power button signal
Orange - Keyboard Out
Red - Keyboard In
Brown - Vcc
ATmega32u4 connections (pinout provided for Arduino Pro Micro):
Keyboard out (orange) : PD0 (pin 3)
Keyboard in (red) : PD1 (pin 2)
Power Button (yellow) : PD4 (pin 4)
Ground (black) : GND
Vcc (brown) : VCC
See attached next_timings.jpg file for a detailed illustration of NeXT keyboard protocol timings.
Power button signal line is normally high when the keyboard is powered/initialized. It is pulled to ground when pressed. The converter automatically translates this to a "normal" keypress with code 0x5A. This connection is technically optional, the only side effect of not making this connection is the power key will do nothing.
Converter is based heavily on Ladyada's original "USB NeXT Keyboard with Arduino Micro" tutorial (http://learn.adafruit.com/usb-next-keyboard-with-arduino-micro/overview). If you build this converter, show Adafruit some love and do it using an Arduino Micro (http://www.adafruit.com/products/1315) or their ATmega 32u4 Breakout Board (http://www.adafruit.com/products/296). Arduino Micro should work fine using the Arduino Pro Micro configuration above, same pins numbers and everything.
TODO:
-----
I believe it might be possible to run the keyboard off of 3V; during testing I observed that the keyboard could sometimes function even without Vcc connected as long as the ground connection was good and the Keyboard In line was connected. If that works it should be easy to do a Bluetooth conversion and run the keyboard right off of a LiPo battery without a boost circuit
Utilize second LED as status indicator for good initialization; also try to make hot plugging much more robust.
Figure a better use for the Power button. Too easy to hit it by mistake to use for Suspend or Power Off - maybe move cap to different part of the board and consider that
Figure out a better use for the lock LEDs. Right now they just light up when you press shift. Lame. Maybe implement proper Caps/Num/Scroll Locks
This firmware converts PS/2 keyboard protocol to USB.(It supports Scan Code Set 2.)
Connect Wires
-------------
In case of Teensy2.0(ATMega32U4):
1. Connect **Vcc** and **GND**.
2. Connect **Clock** and **Data** line.
- **Interrupt**: **Clock** is on `PD1` and **Data** on `PD0`.(Recommended. Soarer's converter compatible)
- **Busywait**: **Clock** is on `PD1` and **Data** on `PD0`.
- **USART**: **Clock** is on `PD5` and **Data** on `PD2`.
3. Optionally you need pull-up resistor. 1K-10K Ohm is OK.
To change pin configuration edit **config.h** and **Makefile**.
Build Firmware
--------------
For **PJRC Teensy** just run `make`:
$ make clean
$ make
To select keymap:
$ make clean
$ make KEYMAP=[plain|jis|spacefn|...]
After that you will find HEX file `ps2_usb_lufa.hex` in current directory.
- For **TMK converter Rev.1** use `make -f Makefile.tmk_rev1` instead of `make` and HEX file is `ps2_usb_tmk_rev1.hex`.
- For **TMK converter Rev.2** use `make -f Makefile.tmk_rev2` instead of `make` and HEX file is `ps2_usb_tmk_rev2.hex`.
Keymap
------
Several version of keymap are available in advance but you are recommended to define your favorite layout yourself. To define your own keymap create file named `keymap_<name>.c` and see keymap document(you can find in README.md of top directory) and existent keymap files.
PS/2 signal handling implementations
------------------------------------
Following three methods can be used to implement PS/2 signal handling.
### Simple and stupid busy-wait(ps2_busywait.c)
This is expected to implemented with portable C code for reference.
### Interrupt driven(ps2_interrupt.c)
Uses pin interrupt to detect falling edge of clock line.
### USART hardware module(ps2_usart.c)
Uses AVR USART engine to receive PS/2 signal.
To select method edit Makefile.
V-USB Support
-------------
With V-USB you can use this converter on ATmega(168/328) but it doesn't support NKRO at this time.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
