qmk/qmk_firmware

Describe the Bug I'm designing a new keyboard and added my QMK_HOME as a submodule of the repo I'm using to track the process. This setup causes qmk doctor to report "QMK home does not appear to be a Git repository!" and skip the remainder of the Git checks. Digging into the code, this is just a matter of qmk doctor expecting <qmk_home>/.git to be a directory, but in submodules and worktrees it's a file. I've put together a PR to address this (and a couple of other things I found while in there), which I'll be posting momentarily. Keyboard Used N/A Link to product page (if applicable) N/A Operating System Arch Linux qmk doctor Output Ψ QMK Doctor is checking your environment. Ψ Python version: 3.14.7 Ψ CLI version: 1.2.0 Ψ QMK home: /home/five35/Documents/Projects/Q535/qmk_firmware Ψ Detected Linux (Arch Linux). Ψ Userspace enabled: False ⚠ QMK home does not appear to be a Git repository! (no .git folder) Ψ All dependencies are installed. Ψ Found arm-none-eabi-gcc version 16.

Describe the Bug Hello, I have a Round 2 B104 beam spring with the Leyden Jar controller, and I love it. I ran into one small fault and believe I have found the cause, so I wanted to pass it along. Symptom On my home PC (Windows, keyboard plugged directly into the motherboard), the Num Lock, Caps Lock, and Scroll Lock LEDs went dark after roughly 30 to 60 minutes of normal use. The PC had not gone to sleep and the keys kept working. Pressing the lock keys still changed the state in Windows, but the LEDs stayed dark. Unplugging the keyboard, or pressing a key mapped to QK_REBOOT, brought them back. The solenoid was off. The fault did not appear on my work computer over a full day. Likely cause In keyboards/leyden_jar/io_expander.c, the IO expander is configured only once, in io_expander_init(). After that, io_expander_update_state() writes the output register only when the LED state changes. If the chip ever loses its configuration and its pins revert to inputs, nothing restores it, whi

Describe the Bug On current master, a clean build of gmmk/pro/rev1/ansi with the default keymap only lights the LEDs controlled by the second AW20216S driver (right-hand columns and side strips). All LEDs on the first driver (indices 0–65, most of the board) stay dark and don't respond to RGB Matrix changes. Hardware is fine: the prebuilt VIA/Vial firmware lights every LED correctly. Pin config on master matches the older working Vial config (CS B13/B14, EN C13, SPI A5/A6/A7), so pins aren't the issue. Adding this to the keymap's config.h fixes it completely: #define AW20216S_SPI_DIVISOR 8 This suggests the first driver can't reliably handle the default SPI clock on at least some rev1 boards. Consider setting a higher default divisor for this keyboard. Keyboard Used gmmk/pro/rev1/ansi Link to product page (if applicable) https://www.gloriousgaming.com/products/gmmk-pro-black-slate-75-barebone Operating System macOS qmk doctor Output Ψ QMK Doctor is checking your environment. Ψ Pyt

Describe the Bug Summary For a key that's part of a combo, last_matrix_activity_time (and therefore last_input_activity_elapsed()) gets updated at the moment the key is physically pressed. Naturally, that happens before process_combo() decides whether to actually dispatch it. If the combo doesn't complete and the key is replayed via the buffer after COMBO_TERM, any keymap code that reads last_input_activity_elapsed() inside process_record_user() for that key sees only the few milliseconds since its own (delayed) replay, not the real time since the previous keystroke. Non-combo keys don't have this problem: their process_record_user() call happens synchronously, before keyboard_task() updates the activity timer for that press. Why this matters Any keymap logic gated on "was the previous key pressed within N ms" (adaptive key swaps, achordion-style timing, etc.) silently stops respecting the timeout for any key that also happens to be part of a combo. The check basically always passes. R

Feature Request Type Core functionality Add-on hardware support (eg. audio, RGB, OLED screen, etc.) Alteration (enhancement/optimization) of existing feature(s) New behavior Description Summary I am developing an ArduinoCore for Microchip’s AVR DU family MCU. I wanna adding support for AVR DU family to QMK firmware — would it be possible to include it via some pull requests? Currently, developing prototypes of ProMicro and XIAO form factor boards with the goal of bringing them to market by the end of 2026. And I have already checked that the actual QMK products with customized QMK firmware perform basic operations. Abouts AVR DU AVR DU is next generation 8-bit MCU include USB controller that is many software compatible with the ATmega32U4 and outperforms it in many areas. It operates at up to 24 MHz without a crystal oscillator at both 3.3 V and 5 V, and can maintain a frequency error of ±0.2% through auto-tuning using USB communication. Since it just went on sale in 2024 a