With newlib_libc enabled, a warning was printed for this sprintf.
The settings_name may expand to 17 characters instead of the available
15.
Fixes#808.
Full warning:
[49/272] Building C object CMakeFiles/app.dir/src/ble.c.obj
In file included from /home/okke/.local/zephyr-sdk-0.11.2/arm-zephyr-eabi/arm-zephyr-eabi/sys-include/stdio.h:800,
from ../../src/ble.c:12:
../../src/ble.c: In function 'set_profile_address':
../../src/ble.c:118:27: warning: '%d' directive writing between 1 and 3 bytes into a region of size 2 [-Wformat-overflow=]
118 | sprintf(setting_name, "ble/profiles/%d", index);
| ^~~~~~~~~~~~~~~~~
../../src/ble.c:118:41: note: format string is defined here
118 | sprintf(setting_name, "ble/profiles/%d", index);
| ^~
In file included from /home/okke/.local/zephyr-sdk-0.11.2/arm-zephyr-eabi/arm-zephyr-eabi/sys-include/stdio.h:800,
from ../../src/ble.c:12:
../../src/ble.c:118:27: note: directive argument in the range [0, 255]
118 | sprintf(setting_name, "ble/profiles/%d", index);
| ^~~~~~~~~~~~~~~~~
../../src/ble.c:118:5: note: '__builtin___sprintf_chk' output between 15 and 17 bytes into a destination of size 15
118 | sprintf(setting_name, "ble/profiles/%d", index);
| ^~~~~~~
With newlib_libc enabled, a warning was printed for this memcpy.
uuid is a `bt_uuid_128`, while BT_UUID_GATT_CCC is only `bt_uuid_16`.
Fixes#808.
Full warning:
[53/272] Building C object CMakeFiles/app.dir/src/split/bluetooth/central.c.obj
In file included from /home/okke/.local/zephyr-sdk-0.11.2/arm-zephyr-eabi/arm-zephyr-eabi/sys-include/string.h:180,
from /home/okke/dev/zmk/zephyr/include/bluetooth/bluetooth.h:21,
from ../../src/split/bluetooth/central.c:9:
../../src/split/bluetooth/central.c: In function 'split_central_discovery_func':
../../src/split/bluetooth/central.c:130:9: warning: '__builtin_memcpy' forming offset [5, 17] is out of the bounds [0, 4] of object '({anonymous})' with type 'struct bt_uuid_16[1]' [-Warray-bounds]
130 | memcpy(&uuid, BT_UUID_GATT_CCC, sizeof(uuid));
| ^~~~~~
/home/okke/dev/zmk/zephyr/include/bluetooth/uuid.h:72:45: note: '({anonymous})' declared here
72 | ((struct bt_uuid *) ((struct bt_uuid_16[]) {BT_UUID_INIT_16(value)}))
| ^
/home/okke/dev/zmk/zephyr/include/bluetooth/uuid.h:372:2: note: in expansion of macro 'BT_UUID_DECLARE_16'
372 | BT_UUID_DECLARE_16(BT_UUID_GATT_CCC_VAL)
| ^~~~~~~~~~~~~~~~~~
../../src/split/bluetooth/central.c:130:23: note: in expansion of macro 'BT_UUID_GATT_CCC'
130 | memcpy(&uuid, BT_UUID_GATT_CCC, sizeof(uuid));
Quick release for sticky keys failed for non-layer keys. The sticky key
was released just before the key that was supposed to be modified was
handled.
The issue was caused by an error in the sticky key logic, which released
the sticky key before handling the key up event.
Fixes#696.
Previously the colors of operating systems were the same both for dark
and light color scheme. That's not a major issue, but adjusting the
colors for the dark theme to better match the theme looks like an
improvement.
Colors were just darkened by reversing the lightness of each color taken
from the dark theme.
Now, instead of always defaulting to light theme, documentation, docs
will default to the color scheme based by the user preference (reported
by web browser as a `prefers-color-scheme` media query).
It is still possible for user to change the theme by using the switch
next to the search box. His preference will be remembered.
To properly retrigger hold-taps when a combo is not activated, some
position down events are reraised instead of released. The corresponding
position up events were never reraised, causing a potential stuck key.
* Update underglow.md
Updated the documentation according to my current understandring of how to pin-mapping works, also split the chapter into a nrf-section and a non-nrf-section since that information isn't applicable to both
* Ran prettier and updated pin reference according to suggestion
This is an improvement on retro-tap, solving the 'flashing hold' issue
users people experience.
When the tapping-term expires, the hold key is normally pressed. When
retro-tap is enabled, this is undesirable; only an interrupted hold-tap
should trigger the hold behavior.
This change disables the hold behavior for the 'STATUS_HOLD_TIMER'
state when retro-tap is enabled, and makes sure the
'STATUS_HOLD_INTERRUPT' state will be triggered when appropriate.