* Nix: Allow calls to `bin/qmk` even when the build was started by `qmk`
The `$PATH` modifications performed by the Nix wrapper for the `qmk`
executable prevent `bin/qmk` from working properly (the changed `$PATH`
contains a wrong `python3` executable which does not have the needed
Python modules in its module path). As a workaround, disable the
generation of that wrapper for the `qmk` Python package (there is yet
another wrapper generated while building the Python environment, which
would still set the Python module path properly when running `qmk`).
Although `bin/qmk` is officially deprecated, QMK CLI still invokes it in
some cases (at least `qmk doctor` and `qmk pytest`), therefore keeping
these invocations working is useful.
* Nix: Update `util/nix/pyproject.toml` to match `requirements*.txt`
Update the Python dependency information used by Poetry to match the
current state of the qmk_firmware code.
* Nix: Bump QMK CLI dependency to 1.0.0; bump other Python deps
Update Python dependencies for nix-shell to the most recent releases:
- dotty-dict: 1.3.0 -> no longer used
- milc: 1.4.2 -> 1.6.2
- pep8-naming: 0.11.1 -> 0.12.1
- pygments: 2.9.0 -> 2.10.0
- pyrsistent: 0.17.3 -> 0.18.0
- pyusb: 1.1.1 -> 1.2.1
- setuptools-scm: 6.0.1 -> no longer used
- qmk: 0.1.0 -> 1.0.0
- qmk-dotty-dict: not used -> 1.3.0.post1
- yapf: 0.30.0 -> 0.31.0
Note to self: The command to update Python dependencies changed to:
( cd util/nix && nix run 'nixpkgs#poetry' -- update --lock )
* Add HOLD_ON_OTHER_KEY_PRESS option for dual-role keys
Implement an additional option for dual-role keys which converts the
dual-role key press into a hold action immediately when another key is
pressed (this is different from the existing PERMISSIVE_HOLD option,
which selects the hold action when another key is tapped (pressed and
then released) while the dual-role key is pressed). The Mod-Tap keys
already behave in a similar way, unless the IGNORE_MOD_TAP_INTERRUPT
option is enabled (but with some additional delays); the added option
makes this behavior available for all other kinds of dual-role keys.
* [Docs] Update tap-hold docs for HOLD_ON_OTHER_KEY_PRESS
Document the newly added HOLD_ON_OTHER_KEY_PRESS option and update the
documentation for closely related options (PERMISSIVE_HOLD and
IGNORE_MOD_TAP_INTERRUPT).
Use Layer Tap instead of Mod Tap in examples for PERMISSIVE_HOLD and
HOLD_ON_OTHER_KEY_PRESS, because the effect of using these options with
Mod Tap keys is mostly invisible without IGNORE_MOD_TAP_INTERRUPT.
Add comments before return statements in sample implementations of
`get_ignore_mod_tap_interrupt()`, `get_hold_on_other_key_press()` and
`get_permissive_hold()`.
Thanks to @Erovia and @precondition for comments and suggestions to
improve the documentation.
Debian bullseye (testing at the moment, but seems close to release) has
avr-libc 1:2.0.0+Atmel3.6.2-1.1 with some changes taken from the
Atmel-distributed toolchain. In particular, the <avr/io.h> header for
ATmega32A (avr/iom32a.h) now defines the FLASHEND constant as `0x7FFFU`,
and that `U` suffix breaks the firmware size check code, because the
shell arithmetic expansion that is used to calculate `MAX_SIZE` does not
support those C-specific suffixes.
As a workaround, add `-D__ASSEMBLER__` to the C preprocessor invocation
that is used to expand those macros; in this case avr/iom32a.h defines
`FLASHEND` without the `U` suffix, and everything works as it did before
with older avr-libc versions.
The exact same code is present in two places; they are both changed,
even though the code in `tmk_core/avr.mk` is actually never used for
ATmega32A (and the header for ATmega32U4 does not add that `U` suffix to
`FLASHEND` for some reason).
The code using sprintf() did not fit into flash when `merge/um70:via`
was compiled with avr-gcc 5.4.0:
* The firmware is too large! 29756/28672 (1084 bytes over)
Replacing `sprintf(wpm_str, " %03d", current_wpm);` with custom
formatting code reduces the firmware size by 1504 bytes, which is enough
to make the `merge/um70:via` firmware fit:
* The firmware size is approaching the maximum - 28252/28672 (98%, 420 bytes free)
Tap dance callbacks may register weak mods; one case when it happens
is when a tap dance registers a key with modifiers. When the tap
dance is interrupted by pressing another key, these weak mods could
affect the interrupting key (normally any stale weak mods are cleared
at the start of action_exec() when handling a keypress event, but the
tap dance interrupt check code is called later, and the weak mods left
by that code were not cleared). Add another clear_weak_mods() call to
preprocess_tap_dance() to make sure that the interrupting keypress is
not affected by unrelated weak mods from the previous tap dance.
Fixes#12445.
* Fix default ADC_RESOLUTION for ADCv3 (and ADCv4)
Recent ChibiOS update removed ADC_CFGR1_RES_10BIT from the ADCv3 headers
(that macro should not have been there, because ADCv3 has CFGR instead of
CFGR1). Fix the default value for ADC_RESOLUTION to use ADC_CFGR_RES_10BITS
if it is defined (that name is used for ADCv3 and ADCv4).
* Update ADC docs to match the actually used resolution
ADC driver for ChibiOS actually uses the 10-bit resolution by default
(probably to match AVR); fix the documentation accordingly. Also add
both ADC_CFGR_RES_10BITS and ADC_CFGR1_RES_10BIT constants (these names
differ according to the ADC implementation in the particular MCU).
* Fix pinToMux() for B12 and B13 on STM32F3xx
Testing on STM32F303CCT6 revealed that the ADC mux values for B12 and
B13 pins were wrong.
* Add support for all possible analog pins on STM32F1xx
Added ADC mux values for pins A0...A7, B0, B1, C0...C5 on STM32F1xx
(they are the same at least for STM32F103x8 and larger F103 devices, and
also F102, F105, F107 families). Actually tested on STM32F103C8T6
(therefore pins C0...C5 were not tested).
Pins F6...F10, which are present on STM32F103x[C-G] in 144-pin packages,
cannot be supported at the moment, because those pins are connected only
to ADC3, but the ChibiOS ADC driver for STM32F1xx supports only ADC1.
* Add support for all possible analog pins on STM32F4xx
Added ADC mux values for pins A0...A7, B0, B1, C0...C5 and optionally
F3...F10 (if STM32_ADC_USE_ADC3 is enabled). These mux values are
apparently the same for all F4xx devices, except some smaller devices may
not have ADC3.
Actually tested on STM32F401CCU6, STM32F401CEU6, STM32F411CEU6 (using
various WeAct “Blackpill” boards); only pins A0...A7, B0, B1 were tested.
Pins F3...F10 are inside `#if STM32_ADC_USE_ADC3` because some devices
which don't have ADC3 also don't have the GPIOF port, therefore the code
which refers to Fx pins does not compile.
* Fix STM32F3xx ADC mux table in documentation
The ADC driver documentation had some errors in the mux table for STM32F3xx.
Fix this table to match the datasheet and the actual code (mux settings for
B12 and B13 were also tested on a real STM32F303CCT6 chip).
* Add STM32F1xx ADC pins to the documentation
* Add STM32F4xx ADC pins to the documentation
The dac_basic driver did not work properly with `#define AUDIO_PIN A4`
(instead of configuring the A4 pin, the driver actually was switching
the A5 pin to analog mode, breaking any other usage of that pin in
addition to emitting a distorted signal on the improperly configured
A4 pin). Fix the code to configure the A4 pin as intended.
By default the `i2c_master` driver for ChibiOS uses the B6 pin for
`I2C1_SCL` and the B7 pin for `I2C1_SDA`. However, the ChibiOS board
file used for the F401 Blackpill board (`ST_STM32F401C_DISCOVERY`)
configures B6 as `I2C1_SCL` and B9 as `I2C1_SDA`, and if that
configuration is left unchanged, enabling the `i2c_master` driver
results in having two pins (B7 and B9) configured as `I2C1_SDA` at the
same time, which does not work properly (experimental results show that
the B9 pin still works as `I2C1_SDA` in that case, and the B7 pin does
not work).
Configure the B9 pin as an input with pull-up in `board_init()`, so that
the B7 pin can be configured as `I2C1_SDA` by the I2C driver.
The `KEYBOARD_SHARED_EP=yes` option was breaking the VIA support,
because the raw HID interface number in this case was 0 instead of 1,
and the VIA app depends on the exact interface number for raw HID.
Change the interface ordering to put the shared interface before the raw
HID interface if `KEYBOARD_SHARED_EP` is enabled, so that the raw HID
interface can keep its number.
* Fix dirtying in oled_write_pixel()
Set the dirty bit for the block only if oled_write_pixel() actually
changed the buffer state. Without this check oled_write_pixel() could
not be used inside the oled_task_user() code using the “redraw always”
style, because the blocks touched by oled_write_pixel() would always
appear dirty, and oled_render() would not proceed beyond the first such
dirty block.
* Fix oled_write_pixel() with 90/270 degree rotation
Use oled_rotation_width instead of OLED_DISPLAY_WIDTH, so that a rotated
display would be handled correctly.
* Fix compilation with custom OLED_BLOCK_COUNT and OLED_BLOCK_SIZE
Some OLED sizes (e.g., 64×48) may require a nonstandard value of
OLED_BLOCK_COUNT. The documentation says that this value may be
redefined in config.h, but actually trying to redefine it caused a
compile error, because the macro was redefined in oled_driver.c.
Make the OLED_BLOCK_COUNT definition in oled_driver.c respect any
user override, and do the same for OLED_BLOCK_SIZE just in case.
* Fix handling of out-of-range bits in oled_dirty
If a custom OLED_BLOCK_COUNT value is specified, some bits in oled_dirty
may not correspond to existing blocks; however, if those bits are set
somewhere (e.g., by code with sets oled_dirty to ~0 or even -1),
oled_render() would try to handle them and could access memory beyond
oled_buffer and perform hardware operations with out of range values.
Prevent this by masking off unused bits in oled_render(), and also avoid
setting those bits in other functions.
* Fix potentially wrong dirtying in oled_write_char()
oled_write_char() tried to mark the position just beyond the written
character as dirty; use (OLED_FONT_WIDTH - 1) to dirty the last position
still belonging to the character instead.
* Fix `#define OLED_BLOCK_TYPE uint32_t` on AVR
Using uint32_t as OLED_BLOCK_TYPE did not work properly on AVR, because
some bit shifts were performed using 16-bit int. Add explicit casts to
OLED_BLOCK_TYPE to those shifts.
Fix configs to make the `handwired/onekey/blackpill_f401:backlight` and
`handwired/onekey/blackpill_f411:backlight` examples actually compile
and work:
- Use `PWMD5` instead of `PWMD2` for backlight, which matches the
default value of `BACKLIGHT_PAL_MODE` (AF02 for pin A0 is `TIM5_CH1`)
and does not conflict with the default value of `STM32_ST_USE_TIMER`.
- Enable `HAL_USE_PWM` in halconf.h and `STM32_PWM_USE_TIM5` in
mcuconf.h, so that `PWMD5` could be used.
There is no way to invoke the command feature while having just a single
physical key, and disabling that feature fixes build for keymaps like
`handwired/onekey/promicro:rgb` without resorting to LTO (the command
feature consumes more than 4900 bytes with avr-gcc 8.4.0).
Some STM32 chips have STM32_DMA1_STREAM1 as the first DMA stream, others
(F4xx, F7xx, H7xx) have STM32_DMA1_STREAM0. Instead of those names, use
STM32_DMA_STREAM(0), which should always give the first stm32_dma_stream_t
structure in the DMA streams array, so that the stream ID would be
calculated correctly.
* Add `st-flash` flash target
Add support for flashing the firmware via the `st-flash` utility from
the STLink Tools package (https://github.com/stlink-org/stlink).
* Add `st-flash` to the `qmk flash -b` output
Apparently VIA allocates bits in the layout options field from the
lowest bit, but starting from the **last** option defined in the JSON
file. So the default value 0x06 was actually trying to set the value
`3` (`0b11`) for the second-to-last option ("Right Shift"), which had
only 3 values defined, and the attempt to set an undefined option value
caused the VIA app to hang with a black window.
Fix the default layout options so that it works as intended (the
"Macropad" and "65% Column" options are set).
PR #9307 fixed the immediately visible problem (the command that was
added to $HOME/.bashrc was incorrect because of missing quotes around
paths with spaces). However, the modified command is still wrong - it
captures the value of $PATH at the setup time, and the resulting command
written out to $HOME/.bashrc will overwrite $PATH with that captured
value, ignoring any changes in the environment. This may be especially
important for WSL, where the initial value of $PATH in Linux includes
everything which has been added to %PATH% on the Windows side; after
adding that command to $HOME/.bashrc the WSL environment will no longer
pick up any changes made by newly installed Windows software.
Instead of that, use single quotes around the command, so that the
environment variables are not expanded at the setup time, and the
command that is added to $HOME/.bashrc becomes exactly this:
PATH="$HOME/.local/bin:$PATH"
This command will use the $HOME and $PATH environment variable values at
the time the command is executed, not at the time the QMK setup is
performed, so any further updates to $PATH are taken into account.
Double quotes also ensure that the command is safe even if the values of
those environment variables contain spaces.
A user in Discord reported that the right bracket and ISO hash keys on
KBD67 rev2 using LAYOUT_65_iso were swapped. When comparing
LAYOUT_65_iso with LAYOUT_65_ansi, the problem with a wrong assignment
of the right bracket key is obvious — that key is K1D in the ANSI layout
macro, but the ISO layout macro had K1E there, and K1D at the position
of the ISO hash key.
Fix the LAYOUT_65_iso macro by swapping those arguments (and also align
the K1D argument for the right bracket key properly).
* id80: Transpose matrix to use faster COL2ROW routines
Even the standard QMK matrix_scan() function can give about 2 times
higher scan rate (if compiled with optimizations enabled) if the COL2ROW
matrix layout is used instead of ROW2COL. Although the ID80 PCB is
wired using the ROW2COL matrix layout, it is possible to transpose the
matrix from the QMK standpoint, so that "columns" would correspond to
horizontal connections, and "rows" would correspond to (mostly) vertical
connections; in this case the matrix could be handled as if it had the
COL2ROW layout.
The matrix layout change makes the older VIA JSON layout definition
incompatible, but the corresponding JSON was not yet accepted to the VIA
repository, so it should still be safe to make this change.
* id80: Remove obsolete comments
* id80: New keyboard (IDOBAO ID80)
Add initial support for the IDOBAO ID80 keyboard.
Most source files were generated by the KBFirmware JSON to QMK Parser
(https://noroadsleft.github.io/kbf_qmk_converter/) based on the
ID80.json file provided by the keyboard vendor. The only change to
rules.mk was to set `COMMAND_ENABLE = no` to make the compiled firmware
fit into the available flash space.
* id80: Update default keymap to match stock
Update the Fn layer in the default keymap to match the stock firmware
which was actually flashed into the PCB.
* id80: Add Caps Lock indicator support
Although the KBFirmware JSON includes information about the MCU pins
used for keyboard indicator LEDs, the KBF to QMK converter does not
generate the required code automatically. Implement the LED handling
code, and at the same time switch from the older `led_set_kb` API to the
newer `led_update_kb`.
* id80: Remove placeholder functions
The provided skeletons for `matrix_scan_kb` and `process_record_kb` did
not do anything useful, so remove them.
* id80: Use Esc as the Bootmagic Lite activation key
The Esc key is not at the (0, 0) position in the ID80 matrix, therefore
setting `BOOTMAGIC_LITE_ROW` and `BOOTMAGIC_LITE_COLUMN` is required to
use the Esc key for Bootmagic Lite.
* id80: Update info.json
Replace info.json generated by the KBF to QMK converter with another
version generated using http://www.keyboard-layout-editor.com/ and the
KLE raw to QMK info.json converter (https://qmk.fm/converter/). The
updated info.json has the correct physical layout (the distance between
the function key row and the main block is actually 0.25U, but the
vendor-provided ID80.json had 0.5U there) and correct key labels (using
the stock layout instead of raw matrix locations and pin names).
* id80: Enable NKRO
The default keymap is updated to have NK_TOGG at Fn+N, like most other
keyboards which have NKRO enabled.
* id80: Use unique USB vendor/product ID
Having an unique USB vendor/product ID is required for VIA support.
The vendor ID value is the same as for the `idobo` (ID75) keyboard.
* id80: Fix right modifiers in the default keymap
For some reason the default keymap converted from the vendor-supplied
JSON had the right Shift, Alt and Ctrl keys mapped to the left side
modifier keycodes.
* id80: Remove empty row 6 (F0) from matrix
The matrix layout which was defined in the vendor-supplied ID80.json
file had 12 rows which corresponded to the left and right parts of the
6 physical rows. However, the row 6 of the matrix (connected to the F0
pin), which corresponded to the right part of the physical bottom row,
was completely empty (all 9 keys of the bottom row were placed in the
matrix row for the left part). Keeping this row in the matrix just
wastes resources; in particular, when the VIA support is enabled, having
a 9×12 matrix with 4 layers leaves only 122 bytes available for dynamic
macros, which is less than the recommended minimum of 128 bytes.
Removing the unused row reduces the matrix size to 9×11, which leaves
194 bytes of EEPROM space for dynamic macros.
* id80: Update row numbers in the LAYOUT macro
Update row numbers in the names of the LAYOUT macro parameters after
removing a row in the middle.
* id80: Set RGBLED_NUM to 20 to match the actual PCB
The vendor-supplied ID80.json file specified that the PCB should have
28 RGB LEDs in the chain. However, the actual PCB that was shipped
from AliExpress had 20 LEDs in the chain (16 underglow LEDs, and then 4
more LEDs on top of the PCB, to the right of the Enter key location).
Update RGBLED_NUM to match the actual PCB.
Sergey VlasovandGitHub
