Merge branch 'main' into wake-up
This commit is contained in:
commit
7933729eaa
6 changed files with 9 additions and 8 deletions
|
@ -26,6 +26,7 @@
|
|||
;
|
||||
};
|
||||
|
||||
|
||||
/{
|
||||
side_band_behavior_triggers: side_band_behavior_triggers {
|
||||
compatible = "zmk,kscan-sideband-behaviors";
|
||||
|
|
|
@ -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);
|
||||
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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”?
|
||||
|
||||
|
|
|
@ -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">
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
Loading…
Add table
Reference in a new issue