zmkfirmware / zmk Goto Github PK
View Code? Open in Web Editor NEWZMK Firmware Repository
Home Page: https://zmk.dev/
License: MIT License
ZMK Firmware Repository
Home Page: https://zmk.dev/
License: MIT License
Zephyr has a built in feature called Shell that allows issues commands to manipulate the running system. There's an open issue zephyrproject-rtos/zephyr#26122 about enabling this over USB.
We could theoretically should be able to do this over BLE as well if we implement something like Nordic UART Service (NUS) and then a small client utility to connect to the UART and create a virtual TTY for the shell session.
dt-bindings/zmk/keys.h
Potential fix/idea:
key_press
, etc to have the enum flag of the mods included. UGH, but not sure how to avoid this if we want this to also work w/ things like mod-tap, where the other parameter is already used.keys.h
that are + , e.g. something like #define BANG (NUM_1 + HELD_MODS(MOD_LSFT))
I've done some investigations on what good mod-tap behavior could be.
This is a complex matter, as other firmwares like QMK often have many configuration options for the behavior of the mod-taps.
The configuration options exist to make mod-taps work for multiple scenarios, of which homerow mods are one example and things like 'escape-ctrl' on the capslock position another. ZMK needs options to configure the mod-taps, but we should try to keep this as simple as possible.
The modtap proposal for ZMK contains three possible behaviors.
The MOD-preferred behavior (left in pdf) works great for thing like escape-ctrl, where the user wants to have the key trigger as 'control' whenever another key is pressed shortly after. This behavior gives the user the quickest response after key presses, which makes it a good candidate as a default behavior.
In the middle, the balanced option. This behavior is probably good for homerow mods, as it will not active the mods on 'key rolls'. The downside of this behavior is that it needs to wait for keyup or tapping_term, making it a little less responsive than the MOD-preferred behavior.
The tap-preferred behavior (right in pdf) shows what the most extreme option is when taps are preferred. This behavior would only pick the 'mod' when the 'tapping_term' timer has expired. This may be a preferred option for some people using homerow or layer mods. The downside of this option is that the user ALWAYS has to wait for the timer to expire before a mod kicks in, which may be too slow for mod-tap shift and friends.
Conclusion;
Here are a list of improvements still to be made to RGB underglow:
hsb_to_rgb
to use integers instead of floats to improve performance(?)zmk
.From:
We need to settle on the process for end users to create their own keymaps, and how those are managed.
Core question: Do we put all keymaps in ZMK directory, or support external keymaps?
zmk-keymaps-contrib
repository for everyone to share various keymaps? We can eventually have community reviewers there, in addition to core members, etc.This is likely closely related to keyboard definitions/support, where we may want a "incubator" for keyboard definitions "out of tree" also.
HID hosts will write to a USB device that supports and advertises in the report descriptor the status of the caps lock, etc. LEDs so they can enable/disable those for display on the device.
For folks that have keyboards with those lights, or who want to show that in the OLEDs, we need to add support for that to our HID layer.
Discuss, decide and document the initial version of ZMK's development model.
Examples:
We should set up Algolia DocSearch for the site, using https://v2.docusaurus.io/docs/search as a reference.
Our current interrupt code for the matrix scanner has a bug where we do not detect key presses of additional keys on the same "input pin" as an already pressed key.
Sequence:
input1
.input1
GPIO pin.input1
.input1
pin is already active, no new interrupt is triggered, so new new "read the matrix" is executed.Suggested fix: Once a key is pressed/held in the matrix, we should start a timer to start polling the matrix, to check for state changes, so that any additional key presses on other row/column pairs are detected and raised.
Once all the pressed keys are released, we then should stop the timer again, to conserve on power.
We need to implement a combo behavior, allowing key combos to trigger additional behavior in addition to standard single key presses.
The Zephyr USB stack doesn't implement any queue-ing of endpoint writes, so if ZMK attempts to send any HID updates while there's an active write occurring, it may fail. There is a small "retry" tried, but no real queue that is saved while waiting for the write to complete.
Implementing this will help be sure no USB updates are dropped.
Before we can implement split transports, we need each side of a left/right hand split keyboard to know which hand they are.
In particular, in order to send the correct column values for KSCAN events passed over the split transport, a right hand board needs to translate the column by a certain offset before sending the row/column/pressed state over the transport.
"Left/Right" detection can be implemented as separate DT overlay files that are included for a separate build/flash cycle for each side of the keyboard. Doing so would allow the following:
The left/right hand is set via EEPROM, NVS, or Zephyr settings API, which matches how QMK implements this.
From #4 (comment) there is a need to determine proper setup and steps for flashing from Windows when building from WSL2.
From: https://discord.com/channels/719497620560543766/719565084208398406/720011568749871124
There's some truly required items necessary before broader marketing/publishing of the ZMK effort. Based on lots of Discord chats, we should at least get these items in place:
Discuss, decide, create and document contribution guidelines.
References:
From: https://discord.com/channels/719497620560543766/719565084208398406/721311410222792756
Precursor for #11
See thread of ideas starting from:
https://discord.com/channels/719497620560543766/719565084208398406/721449184133382154
Currently @ 2.3.0-rc1.
Keymap feature to be implemented: tap dance, allowing different behavior depending on the number of taps of a certain key.
With my nice!60 shield definition in my user config, the BLE name doesn't get applied and just shows a MAC address on devices. (https://github.com/Nicell/zmk-config/tree/master/config/boards/shields/nice60)
USB oddly seems to still have the proper name.
Grave escape is an extremely common feature used by keyboards without an F-row. We should be able to implement this neatly with a new behavior.
QMK docs for reference: https://beta.docs.qmk.fm/using-qmk/advanced-keycodes/feature_grave_esc
We should have a leader key behavior that allows you to add custom actions implemented for a certain sequence of keys pressed after the leader key behavior is triggered.
QMK Docs: https://docs.qmk.fm/#/feature_leader_key
I would imagine there would be something like:
&leader
In your keymap, and you would customize the leader behavior registration itself, elsewhere in the keymap, e.g.:
&leader {
sequence_pi {
keycodes = <P I>;
action = <¬_sure_what_goes_here>;
};
sequence_foo {
keycodes = <F O>;
action = <&whatever_it_does>;
};
Good job on the instructions!
To confirm, my distribution should be up to date.
sudo apt update
Hit:1 http://archive.raspberrypi.org/debian buster InRelease
Get:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
Fetched 15.0 kB in 1s (15.9 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
I've encountered two issues so far.
Running
sudo apt install -y
it complained that gcc-multilib
wasn't available which I bypassed by removing it from the command.
Running
pip3 install --user -r zephyr/scripts/requirements.txt
it complained
Collecting cmsis-pack-manager>=0.2.7 (from pyocd>=0.24.0->-r zephyr/scripts/requirements-run-test.txt (line 9))
Downloading https://files.pythonhosted.org/packages/c9/2b/1ac9b85b5ba535ba386467cb9a897e3f460c04f34a305e02b22f86b65367/cmsis-pack-manager-0.2.10.tar.gz (45kB)
100% |████████████████████████████████| 51kB 2.4MB/s
Complete output from command python setup.py egg_info:
Package libffi was not found in the pkg-config search path.
Perhaps you should add the directory containing `libffi.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libffi' found
Package libffi was not found in the pkg-config search path.
Perhaps you should add the directory containing `libffi.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libffi' found
Package libffi was not found in the pkg-config search path.
Perhaps you should add the directory containing `libffi.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libffi' found
Package libffi was not found in the pkg-config search path.
Perhaps you should add the directory containing `libffi.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libffi' found
Package libffi was not found in the pkg-config search path.
Perhaps you should add the directory containing `libffi.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libffi' found
c/_cffi_backend.c:15:10: fatal error: ffi.h: No such file or directory
#include <ffi.h>
^~~~~~~
compilation terminated.
...
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-install-e44et2su/cmsis-pack-manager/
so I installed libffi-dev
sudo apt-get install libffi-dev
and then reran
pip3 install --user -r zephyr/scripts/requirements.txt
it then complained
Downloading https://files.pythonhosted.org/packages/ae/e7/d9c3a176ca4b02024debf82342dab36efadfc5776f9c8db077e8f6e71821/pycparser-2.20-py2.py3-none-any.whl (112kB)
100% |████████████████████████████████| 112kB 1.9MB/s
Building wheels for collected packages: cmsis-pack-manager
Running setup.py bdist_wheel for cmsis-pack-manager ... error
Complete output from command /usr/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-45ylt83v/cmsis-pack-manager/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d /tmp/pip-wheel-bglvsvky --python-tag cp37:
running bdist_wheel
running build
running build_py
creating build/lib
creating build/lib/cmsis_pack_manager
copying cmsis_pack_manager/__init__.py -> build/lib/cmsis_pack_manager
copying cmsis_pack_manager/pack_manager.py -> build/lib/cmsis_pack_manager
copying cmsis_pack_manager/_native__ffi.py -> build/lib/cmsis_pack_manager
copying cmsis_pack_manager/_version.py -> build/lib/cmsis_pack_manager
copying cmsis_pack_manager/_native.py -> build/lib/cmsis_pack_manager
error: [Errno 2] No such file or directory: 'cargo': 'cargo'
----------------------------------------
Failed building wheel for cmsis-pack-manager
which I thought was due to an older version of pip, according to pyocd/cmsis-pack-manager#137
So I upgraded pip:
python3 -m pip install --upgrade pip
but it didn't help the cmsis/cargo error.
I'm still looking into this. Any thoughts please?
Sending page up/down on encoder rotation only supports scrolling the actively focused content on most OSes. If we instead were to expose a HID mouse/trackpad, and send vertical scroll events, the experience may be improved for many scenarios.
Latest template configuration generated with setup.sh won't get built properly by github actions.
This is the step that actually fails.
- name: Rename zmk.uf2 run: cp build/zephyr/zmk.uf2 SHIELD_NAME_left_BOARD_NAME.uf2
Because only an elf file is generated in the previous step.
ZMK already exposes the standard BLE battery service, but doesn't have any code to actually send values to the connected host. Needs a generic implementation that can be plugged for different keyboards as needed.
There are some outstanding items in the implementation of the split BLE support that need to be work on:
BT_SETTINGS
usage to ensure pairing is saved, avoid future MiTMs.(intervalMin + intervalMax) / 2 / 2
on the central to give peripheral key press events to have time to process.Need to add encoder support that is nicely integrated into ZMK. There are already a couple rotary encoder drivers in Zephyr via the sensor API, but there does not appear to be one for standard "EC11" type ALPS (or clone) encoders.
We're continually trying to define (+remember!) terms for concepts commonly used in ZMK related discussions. Moreover, reuse of terms from existing firmware or software has led to some conceptual misunderstandings. This will only compound itself when more contributors and developers join the party.
Let's collate, coalesce and document the language we'd like to use for ZMK. Using pictures where necessary.
Please use this issue for collation and debate of each term.
Keymap feature that needs implementing: layer-tap.
A behavior that binds a key to momentary layer when held, or taps a key when tapped independently.
Keyboards with irregular matrixes (e.g nice60), or with locations in the matrix without keys/pads (e.g. Kyria) need to be able to have keymaps specified with logical order/location in the keymap DT file, and have that mapped to the proper physical location.
Probably needs something like a chosen
node if type zmk,keymap-transform
which points to a transform node that defined the map from a keymap location to a physical location.
We can have conditional code on the presence of such a chosen node, so it only happens for those keyboards.
For:
Could perhaps leverage these examples:
From: https://discord.com/channels/719497620560543766/719565084208398406/721742604055740488
On devices that contain OLEDs, we have the opportunity to do even more security "numeric comparison" when pairing/bonding with SC to actually display the BLE pairing "numeric comparison" value for verification before prompting a user to hit enter after verifying.
We should have some standard checks in place for MRs, to include things like:
Signed-off-by
if we decide to go "Developer Certificate of Origin".Most board replacements have a status LED on them that we can use to notify the user when the board is advertising, when it bonds, and when bonds are cleared. (switching profiles could be a feature in the future too). This would give much better feedback as to what's happening for troubleshooting and just in general.
As reported by @Nicell, the following sequence does not work as expected.
&mo 1
.&kp ESC
) on that newly activated layer.&mo 1
).On the last step, because layer 1
is no longer active, then the behavior that was triggered for the activation is not triggered for the deactivation. Usually, this leads to sending a "key code release" of the key bound on the lower layer instead.
The proposed fix would be something like:
behavior_keymap_binding_pressed
returns 0
, that indicates that the behaviour has "handled" the key position activation, and processing should not continue to lower layers.u8_t key_position_pressed_layer_handler[ZMK_KEYMAP_LEN]
The SPI definition from the nice!nano should be removed because the pins defined there are low drive rated pins by Nordic. This means that you shouldn't run these pins above 10kHz otherwise you may have interference/degraded performance with the antenna. This is somewhat a design flaw of the nice!nano, however, I don't think it's a big deal.
While the Pro Micro pinout defines SPI, no AVR keyboard uses SPI from my understanding. Instead, bit-banging is used. In fact, it seems many keyboards don't even use those SPI pins for bit-banging (which is good news for the nice!nano). They utilize seemingly random pins because they use bit-banging.
Currently the main use of SPI will be addressable RGB lighting (until something else is found). This becomes a bit awkward because of how led_strip
(see here) is defined in the DT. When using SPI, it builds off of an existing SPI definition. However, for each shield, there will most likely be a different pin for RGB. Because of this we can't define inside of the nice!nano or Proton C an SPI output. This compounds with the fact that SPI can't be put on any pin with the Proton C (stm32 architecture limitation), and the nice!nano can't have SPI on any pin without degrading the antenna.
The solution for board + shield duos using SPI peripherals is for the shield to define the SPI. Once again though, we can't assume every pro micro compatible board is capable of having SPI on the pins defined in the shield. Is it possible to make different definitions for each board? If not, shields should probably utilize the bit-banged version of led_strip
.
Bit-banging will theoretically work on any board, but there's still a couple issues. First, the bit-banged version of the WS2812 driver isn't implemented for every architecture. Second is that still you can't bit-bang on low drive rated pins without degrading wireless performance. There still probably needs per-board definitions for shields to adjust the led_strip
definition.
Tested on both Catalina 10.15.6 and Big Sur Public Beta 5.
Device connects but is not advertised as a keyboard (icon does not indicate keyboard) and is only shown as a MAC address.
When connected, it works and behaves fine, so this appears to be a minor graphical issue.
Various files used starter files with Apache 2.0 headers that got left that way.
Need to audit and update to properly reflect MIT license everywhere.
Initiail version of FAQs. Required by #7.
Currently a realtime work-in-progress on Google Docs. Please contact me on Discord if you need the link to contribute.
While setting up a brand new Fedora based development environment based on the included documentation, I noticed a failure in the Zephyr SDK installation step related to a missing bzip executable.
[vagrant@fedora32 ~]$ sh "zephyr-toolchain-arm-${ZSDK_VERSION}-setup.run" --quiet -- -d ~/.local/zephyr-sdk-${ZSDK_VERSION}
Installing SDK to /home/vagrant/.local/zephyr-sdk-0.11.2
Creating directory /home/vagrant/.local/zephyr-sdk-0.11.2
Success
[|] Installing arm tools...tar (child): bzip2: Cannot exec: No such file or directory
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting no
I was able to resolve the issue by installing bzip manually and after following the rest of the documentation I can successfully build firmware with the west
command.
This is obviously a trivial issue but I find that a seamless dev onboarding makes for a more welcoming experience for potential contributors
The incorrect keycode is released when the layer is changed after a key is pressed. Having a transparent layer above the key will mask the issue as it falls back to the correct layer.
https://discordapp.com/channels/719497620560543766/719544230497878116/747875909016617002
To aid in adoption of ZMK, it would be great to support converting info.json
files into DT overlay keymaps for user config repositories.
Zephyr has advanced Power Management capabilities that we should leverage to make ZMK powered keyboards very power efficient.
It will become increasingly important to track which board, shields and maps are being built and/or used to aid planning and maintainence. Without it the project will be flying blind. This won't require any personal data but may require clear terms if integrated into builds/website.
From: https://discord.com/channels/719497620560543766/719565084208398406/720648126494408744
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.