Merge branch 'zmkfirmware:main' into main

This commit is contained in:
Yaroslav Kondratev 2024-08-28 12:47:16 +03:00 committed by GitHub
commit 1b19eb47c4
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
5 changed files with 8 additions and 8 deletions

View file

@ -24,13 +24,13 @@ struct layer_status_state {
static void set_layer_symbol(lv_obj_t *label, struct layer_status_state state) {
if (state.label == NULL) {
char text[7] = {};
char text[8] = {};
sprintf(text, LV_SYMBOL_KEYBOARD " %i", state.index);
snprintf(text, sizeof(text), LV_SYMBOL_KEYBOARD " %i", state.index);
lv_label_set_text(label, text);
} else {
char text[13] = {};
char text[14] = {};
snprintf(text, sizeof(text), LV_SYMBOL_KEYBOARD " %s", state.label);

View file

@ -35,7 +35,7 @@ static struct output_status_state get_state(const zmk_event_t *_eh) {
}
static void set_status_symbol(lv_obj_t *label, struct output_status_state state) {
char text[10] = {};
char text[20] = {};
switch (state.selected_endpoint.transport) {
case ZMK_TRANSPORT_USB:

View file

@ -57,7 +57,7 @@ For keyboards, this is one of two options:
### What is a “shield”?
In ZMK, a _shield_ is a _PCB_ or _hardwired set of components_ that when combined with a MCU only [board](#what-is-a-board) like the Proton-C or nice!nano, results in a complete usable keyboard. Examples would be keyboard PCBs like the Kyria or Corne. The _shield_ is usually the big PCB containing all the keys.
In ZMK, a _shield_ is a _PCB_ or _hardwired set of components_ that when combined with an MCU-only [board](#what-is-a-board), like the Proton-C or nice!nano, results in a complete usable keyboard. Examples would be keyboard PCBs like the Kyria or Lily58. The _shield_ is usually the big PCB containing all the keys.
### Why _boards_ and _shields_? Why not just “keyboard”?

View file

@ -149,7 +149,7 @@ When [using GitHub Actions to build ZMK](../user-setup.mdx), once you have obtai
defaultValue="zmk"
values={[
{label: 'Default', value: 'zmk'},
{label: 'Alterative', value: 'alt'},
{label: 'Alternative', value: 'alt'},
]}>
<TabItem value="zmk">

View file

@ -55,7 +55,7 @@ Any changes in ZMK related to split keyboard features might also necessitate doi
Split keyboards with BLE-based split communications (i.e. all officially supported split keyboards) have an internal pairing procedure between the central and each peripheral.
When the central has an open slot for a peripheral, it will advertise for connections (which will not be visible to non-ZMK devices).
Then, any peripheral that has not yet bonded to a peripheral will pair to it.
Then, any peripheral that has not yet bonded to a central will pair to it.
Similar to how [bluetooth profiles](bluetooth.md) are managed between the keyboard and host devices, the bonding information will be stored with the corresponding hardware addresses of the other keyboard part, on both the central and peripheral.
In practice, this means that your split keyboard parts will automatically pair and work the first time they are all on at the same time.