# QMK Monthly 9-12 aka Q1 2020

After a brief hiatus we are back!

## General News

### New Collaborators

Welcome to ridingqwerty aka george, tzarc, Erovia, and mtei as QMK collaborators.

#### ridingqwerty (Pennsylvania, USA)
interests: complicated keymaps, helping people
#### tzarc (Australia)
interests: chibios, core, arm, splits, hardware
#### Erovia (Central Europe)
interests: api, cli
#### mtei (Japan)
interests: split keyboard maintainer

### Operating System Survey
The form was filled out by 549 users. We'd like to thank everyone for taking the time. A few interesting tidbits we've learned from these 549 datapoints:

There are 128 of you who are happily using Configurator without touching code.

All our supported platforms have users, in fact, the numbers are surprisingly balanced between the three major ones:

- Windows: 195
- MacOS: 171
- Linux: 268
- BSD: 9

Quite a few of you use more than one OS:

- one: 333
- two: 116
- three: 49
- four: 13
- five: 4
- even more: 3

A lot of you use Arch or variants. Top 5 Linux distro:

- Ubuntu: 146
- Arch: 95
- Debian: 39
- Manjaro: 38
- Fedora: 24

## New Features (in no particular order of importance)

### ChibiOS Update
After a monumental uplift by tzarc, we are finally running the latest release version of ChibiOS (ver19.1.3). Board configurations of large proportion of the MCUs used in QMK can now be upgraded automatically whenever a new version of ChibiOS is released, so keeping up to date won't be as much of a task. ChibiOS-Contrib and uGFX were also updated accordingly (tzarc).

Huuuuuuuuge thanks also to all the community members who helped test!

### VIA Updates
VIA support has been refactored, and is now a core feature.

Reasonable defaults have been added for the Dynamic Keymap feature's config, making the bar for adding support for features like VIA very low.

Support for additional features in VIA has also been added (RGB Light, encoders) (wilba)

### ARM Improvements
#### Fix for ARM wake from resume crash
Community member xyz contributed a state machine fix to the USB code that prevents QMK from crashing when resuming from sleep. This one took ages to figure out. Thanks xyz!

#### WS2812 drivers
SPI and PWM based drivers had landed in core, offering better performance once configured. See the [WS2812 Driver](https://docs.qmk.fm/#/ws2812_driver) docs for more info.

#### ARM Split
Edging closer and closer, recent work has been setting up the various levels of support that will be initially offered. Our current efforts are currently focused on:

* single-wire protocol, which targets a decent proportion of split keyboards.
* Recent changes in ARM feature parity have increased scope of the project, and there are documented limitations we will need to share soon.
* All work-in-progress has been updated inline with the updated ChibiOS dependency, and ongoing testing looks promising.

If you want to contribute, or have a collection of split keyboards ready for testing, hop on over to our Discord server.

### QMK API Changes
The API that powers [QMK Configurator](https://config.qmk.fm/) has been refactored to use JSON keymaps directly. Now there is no difference between compiling using Configurator and compiling using `qmk compile <configurator_export_file>`.

This makes adding features to Configurator easier. By adding support for a feature to [`qmk compile`](https://docs.qmk.fm/#/cli_commands?id=qmk-compile) developers are enabling that feature for Configurator as well.

### EEPROM Support
QMK gained the ability to store non-volatile data off-chip on external I2C EEPROM devices, as well as the internal EEPROM on STM32 L0xx and L1xx devices. Adding new non-volatile storage options has been simplified by adding a new consistent driver interface. (tzarc)

### Custom Matrix lite
The new ['lite'](https://docs.qmk.fm/#/custom_matrix?id=lite) option aims to reduce the boilerplate code when implementing custom matrix. Less code and more consistent access to features like custom debounce algorithms.

### QMK CLI
The [QMK CLI](https://docs.qmk.fm/#/cli) has grown a lot, and if you haven't checked it out yet you should give it a try. It makes working with QMK easier and faster. From context sensitive compiling to json2c support there's a lot that the QMK CLI can help you with.

#### QMK Doctor

Want to know if your environment is setup correctly? Simply run [`qmk doctor`](https://docs.qmk.fm/#/cli_commands?id=qmk-doctor) to get a report about your system. This information can help others when you are trying to troubleshoot information.

#### Context Sensitive Compile and Flash

The [`qmk compile`](https://docs.qmk.fm/#/cli_commands?id=qmk-compile) and [`qmk flash`](https://docs.qmk.fm/#/cli_commands?id=qmk-flash) commands are smart enough to pick your keyboard and/or keymap based on your current working directory. Simply run them without arguments while you are in your keymap directory.

If it detects the wrong keyboard or keymap you can still override with `qmk compile -kb <keyboard> -km <keymap>`.

#### Build All User Keymaps

Using userspace or have multiple boards? Want to check everything builds in a single command? You can now run `qmk compile -kb all -km <keymap>` to build all your keymaps in one go without building EVERYTHING.

#### Configuration settings

Tired of passing `-kb` and `-km` to every command? Set your user defaults with the new [`qmk config`](https://docs.qmk.fm/#/cli_commands?id=qmk-config) command!

qmk config user.keyboard=<keyboard>
qmk config user.keymap=<keymap>

After that you can run [`qmk compile`](https://docs.qmk.fm/#/cli_commands?id=qmk-compile) with no other arguments, and it will pick the defaults you specified. See all the [nitty gritty details in the documentation](https://docs.qmk.fm/#/cli_configuration).

#### JSON Keymaps

Thanks to the CLI you can now use Configurator exports directly in QMK. Simply save the JSON file as `keymap.json` in the same place you'd otherwise use a `keymap.c`. See the [`clueboard/california`'s default keymap](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/california/keymaps/default) for an example.

#### Convert Configurator Exports to C

Sometimes you need the extra power of a C file to do what you need. Now you can convert your JSON keymap to a C keymap using [`qmk json2c`](https://docs.qmk.fm/#/cli_commands?id=qmk-json2c):

qmk json2c -o keymap.c configurator_export.json

Keep in mind that QMK will choose a JSON keymap over a C keymap if both are in a directory. Do not name your JSON keymap `keymap.json` if you want to keep it in your keymap's directory.

#### Convert keyboard-layout-editor Raw to info.json

You can use the [`qmk kle2json`](https://docs.qmk.fm/#/cli_commands?id=qmk-kle2json) command to convert Raw Code from [keyboard-layout-editor](http://keyboard-layout-editor.com) into QMK's info.json format.

qmk kle2json <raw_code.kle>

## Changelog

### Housekeeping

These are things that have been done to clean up our codebase and make QMK easier to work on and understand.

* Cleanups to `keymap_extras` (fauxpark)
Improving language-specific keycode aliases to be more consistent and organized
So far: Colemak, Dvorak, Workman, Norman, Danish, Hungarian, Norwegian, Spanish, Swedish, Turkish F & Q, Slovenian, Belgian, French, German, Italian, Brazilian. Portuguese keymap contributed by GitHub user luismbo.
More to come, including Lithuanian, Greek, Estonian, Finnish, Latvian, Serbian, Irish, Czech, Croatian, Russian, Icelandic, US International...
* Added ARM Teensy MCUs to `mcu_selection.mk` (#8026, fauxpark)
* Removed custom matrix and backlight code for PS2AVRGB keyboards (#7396, #7775, fauxpark)
* Enforced `DIODE_DIRECTION` for all non-custom matrix keyboards (#7915, fauxpark)
* Removed PJRC USB stack (#8103, fauxpark)
* syscalls and nanospecs (zvecr plus others)
* save a little space
* use alt debounce on arm
* use snprintf
* not have random features crap out when you compile

### QMK Configurator

#### keymaps

- 145 new default keymaps

#### other

- [Add Favorite Colorway](https://github.com/qmk/qmk_configurator/pull/587) by zekth
Save your favorite colorway and QMK Configurator will always use it by default.
- [Searchable keycodes](https://github.com/qmk/qmk_configurator/pull/567) by yanfali
Can't find a keycode in the interface? Use the search to see possible options.
- [Add One-Shot Mods](https://github.com/qmk/qmk_configurator/pull/492) by noroadsleft and yanfali
[One-Shot Mods](https://docs.qmk.fm/#/one_shot_keys?id=one-shot-keys) are now a keycode option in QMK Configurator.
- [Japanese translation updates](https://github.com/qmk/qmk_configurator/pull/634) by shelaf
- [Add translation feature from CSV](https://github.com/qmk/qmk_configurator/pull/601) by zekth
Translated strings are now saved in CSV files instead of JavaScript.
- [Fixed a bug with dragging and dropping keycodes](https://github.com/qmk/qmk_configurator/pull/669) by yanfali
Reported by robinrabauke

### New Keyboards

- &#x2248;105 new keyboards

### Core Changes
* SEND_STRING now has the ability to embed delays. (#8244, tzarc)
`SS_DELAY(ms)` in a sendstring delays the next character sent for the specified amount of time in milliseconds.
* Added `send_unicode_string()` function for Unicode feature (#8155, #8236, fauxpark)
Instead of writing out your Unicode macros with `send_unicode_hex_string()`, you can now place Unicode characters straight into the string, eg. `send_unicode_string("(ノಠ痊ಠ)ノ彡┻━┻");` It even does emoji!
* Added support for `\a` (ASCII bell character) in sendstring (#7714, fauxpark)
With the Audio feature enabled and `#define SENDSTRING_BELL` in your config.h, your keyboard will now beep at you if you use `\a` in a sendstring :)
* Media and power keys improvements (#8156, fauxpark)
* Unifying the way media/power keys are handled, as well as fixing a bug where power keys weren't registering on ARM boards.
* Improvements to ADC support and documentation on AVR (#7191, fauxpark)
It should now be a little clearer how to use the analog-to-digital converter in QMK.
Functions and supported pins are documented for all MCUs but the ATmega16/32U2, as they do not have an ADC.
* Added short aliases for Magic and Sendstring keycodes (#7541, #7409, fauxpark)
You can now use shorter keycodes such as `NK_TOGG` in your keymap, instead of the more unwieldy `MAGIC_TOGGLE_NKRO`. `SEND_STRING()`'s repertoire of keycodes also includes the short aliases you see in the keycode list in the docs (but with the `X_` prefix instead, of course).
* Consolidated behaviour of `BACKLIGHT_ON_STATE` (#6749, fauxpark)
On AVR, this define now affects boards using a hardware backlight pin, where previously it was only implemented for software backlight.
`BACKLIGHT_ON_STATE` controls what state the pin is in to constitute the backlight being "on" - that is, when the pin is high, or when the pin is low.

# Upcoming Work

## Housekeeping
* `spi_master` for AVR (#8299, fauxpark)
Extracting the SPI routines from the currently AVR-only Adafruit Bluefruit BLE code into a standard driver similar to `i2c_master`.
This is very exciting as it will allow for the Bluefruit SPI Friend to be used on ARM (as soon as an `spi_master` is written for it), and may also open the door for an SPI split transport - SPI operates in the MHz range, compared to I2C which is on the order of several hundred kHz.
* V-USB code cleanup (#8321, #7797, fauxpark)
Paving the way for Raw HID, and thus VIA, to come to your favorite PS2AVRGB board. The first step will be to move the USB driver code into a submodule, so that it can be forked by QMK and modifications cleanly added where necessary.
Another part of this is using the product and vendor strings defined in each keyboard's config.h, like all other boards, instead of from the V-USB usbconfig.h.
* Support for firmware size checks on ARM (#8179, fauxpark)
It's somewhat more difficult to tell how much flash space an ARM chip has available than it is for AVR, however the part number encodes this information, and we can use that to derive the size check.
* ARM/ChibiOS board consolidation (#8330, #8327, tzarc)
One of the main issues with upgrading ChibiOS has been the different configuration files and board configurations used across the keyboards supported by QMK, as well as unintentional side-effects with manufacturers relying on other manufacturers' board definitions (colloquially, copypaste!).
These pave the way to standardising the board support for QMK, and very much simplifies future ChibiOS upgrades. Very early stages, and very much up for discussion. Feel free to chime in!

# Issue Contributors:

fauxpark, noroadsleft, tzarc, ridingqwerty, Erovia, tzarc, skullydazed, drashna, yanfali