vial-kb / vial-qmk

QMK fork with Vial-specific features.

Quantum Mechanical Keyboard Firmware

This is a keyboard firmware based on the tmk_keyboard firmware with some useful features for Atmel AVR and ARM controllers, and more specifically, the OLKB product line, the ErgoDox EZ keyboard, and the Clueboard product line.

Documentation

• See the official documentation on docs.qmk.fm

The docs are powered by Docsify and hosted on GitHub. They are also viewable offline; see Previewing the Documentation for more details.

You can request changes by making a fork and opening a pull request, or by clicking the "Edit this page" link at the bottom of any page.

Supported Keyboards

• Planck
• Preonic
• ErgoDox EZ
• Clueboard
• Cluepad
• Atreus

The project also includes community support for lots of other keyboards.

Maintainers

QMK is developed and maintained by Jack Humbert of OLKB with contributions from the community, and of course, Hasu. The OLKB product firmwares are maintained by Jack Humbert, the Ergodox EZ by ZSA Technology Labs, the Clueboard by Zach White, and the Atreus by Phil Hagelberg.

Official Website

qmk.fm is the official website of QMK, where you can find links to this page, the documentation, and the keyboards supported by QMK.

vial-qmk's Issues

Firmware still too large, even after disabling features

Please forgive me if I'm doing something obvious wrong.

I'm compiling vial-enabled QMK for my Avalanche v4 keyboard, and I've been following the guide here.

I am using a Pro Micro mcu with 28627 bytes of program memory available. My initial compilation was over 40k.
After turning off all optional Vial features, and enabling LTO, the resulting hex file is still too big:

* The firmware is too large! 30352/28672 (1680 bytes over)

My keymaps/vial/rules.mk file:

VIA_ENABLE = yes
VIAL_ENABLE = yes
RGBLIGHT_ENABLE = yes
ENCODER_MAP_ENABLE = yes
LTO_ENABLE = yes
QMK_SETTINGS = no
TAP_DANCE_ENABLE = no
COMBO_ENABLE = no
KEY_OVERRIDE_ENABLE = no

My keymaps/vial/rules.mk file:

#pragma once
#define VIAL_KEYBOARD_UID {0x23, 0x3D, 0x32, 0xDD, 0xC0, 0x95, 0x33, 0xF4}
#define VIAL_UNLOCK_COMBO_ROWS { 0, 1 }
#define VIAL_UNLOCK_COMBO_COLS { 0, 5 }
#define VIAL_COMBO_ENTRIES 1
#define VIAL_KEY_OVERRIDE_ENTRIES 1
#define DYNAMIC_KEYMAP_LAYER_COUNT 1

Is it because I'm using ENCODER_MAP? Or due to RGBLIGHT_ENABLE?

RGB matrix animations not propagating correctly with split keyboard

using keymap : https://github.com/linkpy/vial-qmk/tree/vial/keyboards/splitkb/aurora/sofle_v2/keymaps/vial

i enabled rgb matrix animations and for example for the reactive solid splash one, pressing a key on the right hand will make the splash animation propagate to the left hand, but not the other way around: the animation doesnt propagate to the right hand when i press a key on the left hand.

to reproduice

• enable rgb matrix and solid (multi)splash (for example but the issue happen with all reactive animations that propagate to the other hand)
• set the animation to solid splash
• press a key on the right hand and notice the animation propagates correctly to the left hand
• press a key on the left hand and notice the animation doesnt propagate to the right hand

example :

vid.mov

(note: in this video the left hand doesnt have backlight leds but only underglow one)

[Feature Request] DOIO/KB16 OLED always on option, Shiftkey Lock, and Alt+Gui keys in Quantum

DOIO KB16 Triple Knob Macro Pad feature request:

Is there a way to always have the OLED screen always on? Option to adjust timeouts or toggle the screen would be helpful.

Is there a way to have the OLED screen to always be on? Or at least an option to have a timeout or always on?

The keyboard I'm asking about:

https://github.com/vial-kb/vial-qmk/tree/vial/keyboards/doio/kb16

QMK request:

add Alt+Gui pairs(left and right versions) in quantum and toggle shift lock key (like LShift and Rshift keys).

Alt+Gui combo keys don't exist. Had to customize those keys to function the way I needed.

Reason why I why a shift key toggle lock:

I'm utilizing the knobs on my DOIO KB 16 keyboard to navigate to specific areas in text. Then I'd highlight the text with shift, so I can cut/copy/paste whatever it is. Originally I made it so that it'd always highlight with shift+arrow keys, but I don't always need things to be highlighted. Would be super convenient if there was a shift toggle function for this reason.

Regarding the shift key toggle, I've looked up and tried for hours in different apps to get the shift key to resemble what I need. Basically I need the Shift key to be press forever, until I press it again to turn it off.

Great job on all the work that has been done. Thank you!

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

[Bug] Currently-shipping Libra Mini boards not detectable by Vial due to changed productId

Describe the Bug

The Libra Mini definition in Vial expects productId 0x4C24, but currently-shipping boards have productId 0x4C23. The existing definition is otherwise fully compatible with 0x4C23 boards.

System Information

Keyboard: Libra Mini
Revision (if applicable): 0x4C23 putative rev. 2
Operating system: n/a
qmk doctor output: n/a

Any keyboard related software installed?
n/a

Additional Context

Files currently working with 0x4C23 boards: https://gist.github.com/sehrgut/622edc0f0e3a75bcff367c4cff2a436a

[Bug] Not able to flash another firmware with security on

First time I flash vial firmware, compiled with default settings, which include security feature. Now I played with my custom keyboard settings and try to flash it again via qmk, but controller is not writable, even if I boot to bootloader via vial application.
I use crkbd/rev1 split keyboard and this setup require to flash firmware for both splits.
I need more detailed instruction for split keyboards

Describe the Bug

$ qmk flash -kb crkbd/rev1 -km crandel
Ψ Compiling keymap with make --jobs=1 crkbd/rev1:crandel:flash


Making crkbd/rev1 with keymap crandel and target flash

avr-gcc (GCC) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Size before:
   text    data     bss     dec     hex filename
      0   26098       0   26098    65f2 crkbd_rev1_crandel.hex

Compiling: quantum/via.c                                                                            [OK]
Linking: .build/crkbd_rev1_crandel.elf                                                              [OK]
Creating load file for flashing: .build/crkbd_rev1_crandel.hex                                      [OK]
Copying crkbd_rev1_crandel.hex to qmk_firmware folder                                               [OK]
Checking file size of crkbd_rev1_crandel.hex                                                        [OK]
 * The firmware size is fine - 26098/28672 (91%, 2574 bytes free)
Waiting for USB serial port - reset your controller now (Ctrl+C to cancel)...................................
Device /dev/ttyACM1 has appeared; assuming it is the controller.
Waiting for /dev/ttyACM1 to become writable....................

System Information

Keyboard: crkbd
Revision (if applicable): rev1
Operating system: Arch Linux
qmk doctor output:

$ qmk doctor
Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.1
Ψ QMK home: /data/vial-qmk
Ψ Detected Linux.
Ψ Git branch: vial
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 12.2.0
Ψ Found avr-gcc version 12.2.0
⚠ We do not recommend avr-gcc newer than 8. Downgrading to 8.x is recommended.
Ψ Found avrdude version 7.0
Ψ Found dfu-util version 0.11
Ψ Found dfu-programmer version 0.7.2
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2022-06-11 09:09:45 +0000 --  (f836d24b0)
Ψ - lib/chibios-contrib: 2022-07-27 10:46:15 +0200 --  (d03aa9cc)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b97320)
Ψ - lib/pico-sdk: 2022-05-17 19:19:01 +0200 --  (07edde8)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ QMK is ready to go, but minor problems were found

Any keyboard related software installed?

• AutoHotKey (Windows)
• Karabiner (macOS)
• Other:

Additional Context

combos wrong output[Bug]

Describe the Bug

1

when i set a combos that input is W+LALT and output is an anykey LALT(KC_UP), it should ouput ALT+UP, but it output that ALT+UP, UP.

System Information

Keyboard:
Revision (if applicable):
Operating system:
qmk doctor output:

(Paste output here)

Any keyboard related software installed?

• AutoHotKey (Windows)
• Karabiner (macOS)
• Other:

Additional Context

QMK Issue with RGB layers

I'm facing a strange behavior on my sofle keyboard. I have enabled RGBLIGHT_LAYERS_OVERRIDE_RGB_OFF, so RGB turns ON for layers when the RGB is OFF.

This is my config.h regarding RGBLIGHT

#ifdef RGBLIGHT_ENABLE
    #define RGBLIGHT_SLEEP /* If defined, the RGB lighting will be switched off when the host goes to sleep */
    #define RGBLIGHT_LAYERS
    #define RGBLIGHT_MAX_LAYERS 4
    #define RGBLIGHT_LAYERS_OVERRIDE_RGB_OFF
    #define RGBLIGHT_LAYERS_RETAIN_VAL
    #define RGB_DI_PIN D3
    #define RGBLED_NUM 72
    #define RGBLIGHT_LIMIT_VAL 150
    #define RGB_SPLIT {36,36}
    #define SPLIT_TRANSPORT_MIRROR
    #define RGBLIGHT_SPLIT
    #define RGBLIGHT_EFFECT_RGB_TEST
    #define RGBLIGHT_DEFAULT_HUE 180
    #define RGBLIGHT_HUE_STEP 10
    #define RGBLIGHT_SAT_STEP 10
    #define RGBLIGHT_VAL_STEP 10
#endif

This is my rules.mk

MCU = atmega32u4
BOOTLOADER = halfkay
OLED_ENABLE = yes
OLED_DRIVER = SSD1306
ENCODER_ENABLE = yes
ENCODER_MAP_ENABLE = yes
VIA_ENABLE = yes
VIAL_ENABLE = yes
RGBLIGHT_ENABLE = yes # Enable WS2812 RGB underlight/underglow
SPLIT_KEYBOARD = yes
WPM_ENABLE = yes
EXTRAKEY_ENABLE = yes # Audio control and System control
LTO_ENABLE = yes
VIAL_INSECURE = yes
MOUSEKEY_ENABLE = yes # Mouse keys
# SPLIT_TRANSPORT = custom

QMK_SETTINGS = no
GRAVE_ESC_ENABLE = no
MAGIC_ENABLE = no
COMBO_ENABLE = no
ONE_SHOT_KEYS_ENABLE = no
AUTO_SHIFT_ENABLE = no

KEY_OVERRIDE_ENABLE = no
COMMAND_ENABLE = no # Commands for debug and configuration
CONSOLE_ENABLE = no # Console for debug
SPACE_CADET_ENABLE = no
MIDI_ENABLE = no
RGB_MATRIX_ENABLE = no
BACKLIGTH_ENABLE = no # Enable keyboard backlight functionality
VERBOSE = no
# Do not enable SLEEP_LED_ENABLE with backligth. it uses the same timer as BACKLIGHT_ENABLE
SLEEP_LED_ENABLE = no # Breathing sleep LED during USB suspend
#BACKLIGHT_DRIVER = pwm
BLUETOOTH_ENABLE = no # Enable Bluetooth
AUDIO_ENABLE = no # Audio output

TAP_DANCE_ENABLE = no

AVR_USE_MINIMAL_PRINTF = yes

The problem is that the RGB only turns ON, on the side where the USB cable is plugged and does not "mirror" to the other side.

Ex: I have USB plugged to the left side (defined as master), RGB OFF. I press a layer key and the light goes ON, but only on the left side, the right side (slave) stays with RGB OFF.

It was supposed to send the same data to the slave, but it just won't turn them ON, but if the leds are ON, then by pressing a layer key, RGB layer leds change color on both sides.

Any ideas on what I am missing??

[Bug] 0.6.1 com

Describe the Bug

No response

Keyboard Used

No response

Link to product page (if applicable)

No response

Operating System

No response

qmk doctor Output

No response

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

No response

Issue with multiple pcb versions sharing a keymap folder

I recently ported the Adelais rev4 PCB to Vial (#408) and I'd like to do the same for the Adelais en ciel Rev3 PCB but I've run into an issue. All the Adelais PCBs (both regular RGB and per key RGB) share the same keymap folder but each requires a unique vial.json file. I wouldn't be able to submit a PR for the Adelais en ciel PCB port without overwriting the vial.json for the other PCB.

I can create the PR and submit if it that would help demonstrate the issue.

I'm not sure how common this is across QMK or if this is a one off.

VIAL breaks sleep (Ubuntu)

I'm using KDE Neon (Ubuntu-based), and I'm unable to sleep the PC while the VIAL-programmed keyboard is plugged into USB.

Keymaps failing to build on merge-2023-06-03

These keymaps are currently failing to build on merge-2023-06-03. If we cannot fix them before the next merge (~2 weeks) they will be deleted from vial-qmk.

• handwired/3dpcb @jkutianski
• password @ll3macorn
• akb/vero @rachmansyahbs
• handwired/prkl30 @CountKeepo
• hineybush/h60 @WrinkleKrinkles
• ilumkb/primus75 @cebby2420
• keychron/q7/ansi @adophoxia
• planck/rev6_drop @dijidiji
• studiokestra/galatea @WrinkleKrinkles

See https://github.com/vial-kb/vial-qmk/actions/runs/5305999907

[Bug] When OLED and eeprom are used together, the Combos and Key Overrides functions seem to cause keyboard confusion and crash.

Describe the Bug

System Information

Keyboard:
Revision (if applicable):
Operating system:
qmk doctor output:

(Paste output here)

Any keyboard related software installed?

• AutoHotKey (Windows)
• Karabiner (macOS)
• Other:

Additional Context

I made a homemade ATmega32U4 MCU keyboard and recently added a CAT24C512 EEPROM ( used with previous OLEDs on the I2C bus ) to expand the functionality of Macros.

But after rebuilding the firmware, it was found that the keyboard was unusable.

After multiple attempts, I found that OLED and eeprom functions seem to be still normal,

But the preset key layers and values will switch quickly and randomly, and the RGB function will no longer be available.

At this point, if the key value is pressed, the entire keyboard will immediately hang without any response.

I used the exclusion method to uninstall all the separable functions one by one, and finally found out that it was Vial's problem.

Vial caused the keyboard to go crazy after enabling Combos and Key Overrides functions.

After completely disabling these two functions, eeprom, oled, RGB, and the remaining button functions can all be used normally.

RP2040 fails to build due to platforms/chibios/drivers/wear_leveling/wear_leveling_rp2040_flash.c errors[Bug]

Describe the Bug

when trying to compile custom firmware from QMK with or without vial specific keymaps it is unable to compile due to errors with platforms/chibios/drivers/wear_leveling/wear_leveling_rp2040_flash.c

System Information

Keyboard: WeAct RP2040 microcontroller
Operating system: Debian Sid
qmk doctor output:

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.1
Ψ QMK home: /home/rus/vial-qmk
Ψ Detected Linux.
⚠ Missing or outdated udev rules for 'atmel-dfu' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'kiibohd' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'stm32-dfu' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'apm32-dfu' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'gd32v-dfu' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'bootloadhid' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'usbasploader' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'usbtinyisp' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'md-boot' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Detected ModemManager without the necessary udev rules. Please either disable it or set the appropriate udev rules if you are using a Pro Micro.
⚠ Missing or outdated udev rules for 'caterina' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'hid-bootloader' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
Ψ Git branch: vial
⚠ Git has unstashed/uncommitted changes.
⚠ The official repository does not seem to be configured as git remote "upstream".
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 12.2.1
Ψ Found avr-gcc version 5.4.0
Ψ Found avrdude version 6.3-20171130
Ψ Found dfu-util version 0.11
Ψ Found dfu-programmer version 0.6.1
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2022-06-11 09:09:45 +0000 --  (f836d24b0)
Ψ - lib/chibios-contrib: 2022-07-27 10:46:15 +0200 --  (d03aa9cc)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b97320)
Ψ - lib/pico-sdk: 2022-05-17 19:19:01 +0200 --  (07edde8)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ QMK is ready to go, but minor problems were found

Any keyboard related software installed?
NO

Additional Context

Making domovoyalex/ergodos with keymap vial

arm-none-eabi-gcc (15:12.2.rel1-1) 12.2.1 20221205
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling: .build/obj_domovoyalex_ergodos/src/default_keyboard.c                                    [OK]
Compiling: quantum/keymap_introspection.c                                                           [OK]
Compiling: quantum/quantum.c                                                                        [OK]
Compiling: quantum/bitwise.c                                                                        [OK]
Compiling: quantum/led.c                                                                            [OK]
Compiling: quantum/action.c                                                                         [OK]
Compiling: quantum/action_layer.c                                                                   [OK]
Compiling: quantum/action_tapping.c                                                                 [OK]
Compiling: quantum/action_util.c                                                                    [OK]
Compiling: quantum/eeconfig.c                                                                       [OK]
Compiling: quantum/keyboard.c                                                                       [OK]
Compiling: quantum/keymap_common.c                                                                  [OK]
Compiling: quantum/keycode_config.c                                                                 [OK]
Compiling: quantum/sync_timer.c                                                                     [OK]
Compiling: quantum/logging/debug.c                                                                  [OK]
Compiling: quantum/logging/sendchar.c                                                               [OK]
Compiling: quantum/logging/print.c                                                                  [OK]
Compiling: quantum/bootmagic/bootmagic_lite.c                                                       [OK]
Compiling: quantum/bootmagic/magic.c                                                                [OK]
Compiling: quantum/matrix_common.c                                                                  [OK]
Compiling: quantum/matrix.c                                                                         [OK]
Compiling: quantum/debounce/sym_defer_g.c                                                           [OK]
Compiling: quantum/main.c                                                                           [OK]
Compiling: lib/printf/src/printf/printf.c                                                           [OK]
Compiling: quantum/mousekey.c                                                                       [OK]
Compiling: drivers/eeprom/eeprom_driver.c                                                           [OK]
Compiling: drivers/eeprom/eeprom_wear_leveling.c                                                    [OK]
Compiling: quantum/wear_leveling/wear_leveling.c                                                    [OK]
Compiling: platforms/chibios/drivers/wear_leveling/wear_leveling_rp2040_flash.c                    In file included from platforms/chibios/drivers/wear_leveling/wear_leveling_rp2040_flash.c:9:
In function 'rom_func_lookup_inline',
    inlined from 'pico_program_bulk' at platforms/chibios/drivers/wear_leveling/wear_leveling_rp2040_flash.c:129:91:
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:120:59: error: array subscript 0 is outside array bounds of 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
  120 | #define rom_hword_as_ptr(rom_address) (void *)(uintptr_t)(*(uint16_t *)rom_address)
      |                                                          ~^~~~~~~~~~~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:129:66: note: in expansion of macro 'rom_hword_as_ptr'
  129 |     rom_table_lookup_fn rom_table_lookup = (rom_table_lookup_fn) rom_hword_as_ptr(0x18);
      |                                                                  ^~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:120:59: error: array subscript 0 is outside array bounds of 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
  120 | #define rom_hword_as_ptr(rom_address) (void *)(uintptr_t)(*(uint16_t *)rom_address)
      |                                                          ~^~~~~~~~~~~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:130:41: note: in expansion of macro 'rom_hword_as_ptr'
  130 |     uint16_t *func_table = (uint16_t *) rom_hword_as_ptr(0x14);
      |                                         ^~~~~~~~~~~~~~~~
In function 'rom_func_lookup_inline',
    inlined from 'pico_program_bulk' at platforms/chibios/drivers/wear_leveling/wear_leveling_rp2040_flash.c:130:83:
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:120:59: error: array subscript 0 is outside array bounds of 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
  120 | #define rom_hword_as_ptr(rom_address) (void *)(uintptr_t)(*(uint16_t *)rom_address)
      |                                                          ~^~~~~~~~~~~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:129:66: note: in expansion of macro 'rom_hword_as_ptr'
  129 |     rom_table_lookup_fn rom_table_lookup = (rom_table_lookup_fn) rom_hword_as_ptr(0x18);
      |                                                                  ^~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:120:59: error: array subscript 0 is outside array bounds of 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
  120 | #define rom_hword_as_ptr(rom_address) (void *)(uintptr_t)(*(uint16_t *)rom_address)
      |                                                          ~^~~~~~~~~~~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:130:41: note: in expansion of macro 'rom_hword_as_ptr'
  130 |     uint16_t *func_table = (uint16_t *) rom_hword_as_ptr(0x14);
      |                                         ^~~~~~~~~~~~~~~~
In function 'rom_func_lookup_inline',
    inlined from 'pico_program_bulk' at platforms/chibios/drivers/wear_leveling/wear_leveling_rp2040_flash.c:131:86:
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:120:59: error: array subscript 0 is outside array bounds of 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
  120 | #define rom_hword_as_ptr(rom_address) (void *)(uintptr_t)(*(uint16_t *)rom_address)
      |                                                          ~^~~~~~~~~~~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:129:66: note: in expansion of macro 'rom_hword_as_ptr'
  129 |     rom_table_lookup_fn rom_table_lookup = (rom_table_lookup_fn) rom_hword_as_ptr(0x18);
      |                                                                  ^~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:120:59: error: array subscript 0 is outside array bounds of 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
  120 | #define rom_hword_as_ptr(rom_address) (void *)(uintptr_t)(*(uint16_t *)rom_address)
      |                                                          ~^~~~~~~~~~~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:130:41: note: in expansion of macro 'rom_hword_as_ptr'
  130 |     uint16_t *func_table = (uint16_t *) rom_hword_as_ptr(0x14);
      |                                         ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
 [ERRORS]
 | 
 | 
 | 
make[1]: *** [builddefs/common_rules.mk:362: .build/obj_domovoyalex_ergodos_vial/wear_leveling_rp2040_flash.o] Error 1
Make finished with errors
make: *** [Makefile:414: domovoyalex/ergodos:vial] Error 1

Key overrides don't trigger on key combos on layers other than 0

Don't know if there's a quick fix for this or not or if this is expected behaviour

my goal here was to use layers as a means to change my overrides on my key combos, but what I found was all key combos seem to live in layer 0, so when going into the key override menu you need to enable the overrides for layer 0 even if the combo is being triggered on layer x

Really appreciate any comments or thoughts on this issue

Implement Leader Key from QMK

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

The leader key function that exists in the QMK main branch implemented inside of Vial
Documentation here: QMK Leader Key

Space Cadet Shift/Ctrl not working with non ANSI Layout

Hi, if I select another keyboard layout then QWERTY (german in my case) the keyboard layout itself does work fully as expected. Other features, like Space Cadet Shift, Ctrl. etc. dont work as expected. In german layout the ( ) change to 8 and 9, so LCtrtl goes to ). Is it possible to fix that? I tried to set a any keycode with LCtl_T but cant enter multiple keycodes then.

[Bug]

Describe the Bug

As per site docs I should see Tap dance and `QMK settings tabs but none of them are present.

System Information

Keyboard: Sofle
Revision (if applicable):V2
Operating system: MacOSX
qmk doctor output:

(Paste output here)

Any keyboard related software installed?

• AutoHotKey (Windows)
• [ x] Karabiner (macOS)
• Other:

Additional Context

Can't the knob switch layers? For example setting TO(1) output is N TO(2) output is O. The buttons are used to switch layers normally, the knobs cannot

Can't the knob switch layers? For example setting TO(1) output is N TO(2) output is O. The buttons are used to switch layers normally, the knobs cannot

Update the README.md to talk about Vial

The README.md is still from QMK. Changing it to talk about Vial, and link to Vial resources, would help folks better understand what your project is, and why your fork is different.

How does VIAL handle persistent configuration/saving custom configs onto EEPROM

I have some custom keycodes that change the speed of scrolling. I would like to save the user set speeds to be saved to the EEPROM but it does not look like VIAL has the feature_eeprom in it yet. Is there a different way that this is handled by VIAL?

https://github.com/qmk/qmk_firmware/blob/master/docs/feature_eeprom.md

gitignore via*.json

Since the last merge of upstream QMK, VIA and Vial JSON files have been added to the gitignore.

vial-qmk/.gitignore

Line 99 in d399418

via*.json

This is pretty inconvenient when maintaining keyboards as changes need to be staged manually every time.

git add vial.json -f

Can we remove this line from the gitignore to make our lives easier?

More Macros/Layers

Just started using this on a new keyboard, and after 15 macros there is no way to add more.

I'm not sure if this is already something someone is working on, but I was hoping to use more macros than that - like 40+ for CLI command shortcuts.

Similar story with layers, I was hoping to have 4 or 5 layers just for those commands shortcuts and then other ones for symbols and normal things like that.

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

With QMK I could write unlimited macros and layers, even with configurator you would get 15 layers, and some of the settings in vial refer to those additional layers, so maybe I'm just missing a way to pass that to the vial GUI, or some backdoor that goes around the GUI.

Vial cannot save the selected qmk rgb lighting effect? After re-plugging and unplugging, it turns red again.

Vial cannot save the selected qmk rgb lighting effect? After re-plugging and unplugging, it turns red again.

Error when compiling [Feker IK75] [On-progress]

Never had this error before, with dumbpad (I did MR here) and bento, but it happen for my Feker

refer to this fork commit for the code aad635d

[Bug] Build for RP2040 based keyboards fail

Describe the Bug

Build the code for a 3x3 macropad that uses a raspberry pi pico as MCU fails. To make sure it was not caused by my code I also tried to build vial_example/vial_rp2040:vial but that fails with the same errors.

The following error shows up several times:

./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:120:59: error: array subscript 0 is outside array bounds of 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
  120 | #define rom_hword_as_ptr(rom_address) (void *)(uintptr_t)(*(uint16_t *)rom_address)
      |                                                          ~^~~~~~~~~~~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:130:41: note: in expansion of macro 'rom_hword_as_ptr'
  130 |     uint16_t *func_table = (uint16_t *) rom_hword_as_ptr(0x14);
      |                                         ^~~~~~~~~~~~~~~~

System Information

Keyboard: vial_example/vial_rp2040:vial
Revision (if applicable): -
Operating system: manjaro linux (archlinux based)
qmk doctor output:

~/repos/vial-qmk (ijskegel =) > qmk doctor
Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.1
Ψ QMK home: /home/patrick/repos/vial-qmk
Ψ Detected Linux.
Ψ Git branch: ijskegel
⚠ The official repository does not seem to be configured as git remote "upstream".
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 12.2.0
Ψ Found avr-gcc version 8.5.0
Ψ Found avrdude version 7.0
Ψ Found dfu-util version 0.11
Ψ Found dfu-programmer version 0.7.2
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2022-06-11 09:09:45 +0000 --  (f836d24b0)
Ψ - lib/chibios-contrib: 2022-07-27 10:46:15 +0200 --  (d03aa9cc)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b97320)
Ψ - lib/pico-sdk: 2022-05-17 19:19:01 +0200 --  (07edde8)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ QMK is ready to go, but minor problems were found

Any keyboard related software installed?
no

Additional Context

Updating to the same lib/pico-sdk submodule version as used in qmk solves the issue.
This works for me:

cd lib/pico-sdk
git checkout 8d56ea332b3734cef0a8e61f7d61f2422bd539b1
cd ../..
make vial_example/vial_rp2040:vial

Add info.json for libra mini

I bought a libra mini, but "no devices detected" comes out from vial.
My libra mini has different keyboard_name, vid, pid, device_version.
Can you create an info.json for this?

[Feature Request] Apply Joystick improvements from upstream qmk

Feature Request Type

• Core functionality
• Improve hardware support: Joystick
• Alteration (enhancement/optimization) of existing feature(s)
• New behavior

Description

QMK merged some improvements for the joystick implementation in January: qmk/qmk_firmware#19052

This changed some variables which makes it harder to maintain configurations for qmk and qmk-vial.

Because of these changes following current QMK documentation on how to implement joysticks does not work with Vial any more and will result in failed builds and there is no Vial-specific documentation describing the current implementation in vial. This currently makes it harder to port new devices with Joysticks or analog inputs to Vial.

Here is a summary of improvements copied from the original pull requests:

• Improved documentation, added API reference
• Renamed JOYSTICK_AXES_COUNT/JOYSTICK_AXES_RESOLUTION to singular AXIS to align with JOYSTICK_BUTTON_COUNT
• Replaced enum joystick_status with simple dirty flag in joystick_t
• Added V-USB support
• Added shared EP support for LUFA/ChibiOS

Is it possible to merge these changes in Vial?

Hello, how can I solve this error

Hello, how can I solve this error

[Feature Request] Add support for the Keychron K2 V2.

The keychron K2 V2 is supported by the sonixQMK branch, please add support for this keyboard in Vial.

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

The Keychron K2/K2V2 is supported on the SonixQMK branch and is also supported on VIA from their branch, Vial works for keymapping and macro with the via sideload option, but no RGB control. I'm open to provide any help needed as I own this specific keyboard.

V87 PRO want running in vial

I have a cidooo's V87pro

I want to use tab dance
Unfortunately, however, via does not support that feature, but only vial.
So I'm going to flash with vial.
I prepared these three files, but there are errors.

how can I comfile and use vial?

keymaps.zip

[Bug] linkage error

Describe the Bug

Hi, I found linkage error during creating a pull request for my board(akira-60), and I encounter the same error with other board using the same chip(stm32f042x), the linkage error seems saying there are no enough RAM to fit on the board, but I can compile the board successfully on the qmk/qmk_firmware master.

Linkage Error of the existing board using stm32f042x

Linking: .build/chavdai40_rev1_default.elf                                                          [ERRORS]
 |
 | /usr/local/Cellar/arm-gcc-bin@8/8-2019-q3-update_1/bin/../lib/gcc/arm-none-eabi/8.3.1/../../../../arm-none-eabi/bin/ld:rules_memory.ld:314 cannot move location counter backwards (from 0000000020001da8 to 0000000020001800)
 | collect2: error: ld returned 1 exit status

Compliation Result from qmk/qmk_firmware master

Creating binary load file for flashing: .build/ekow_akira_default.bin                               [OK]
Creating load file for flashing: .build/ekow_akira_default.hex                                      [OK]

Size after:
   text    data     bss     dec     hex filename
      0   21898       0   21898    558a ekow_akira_default.bin

System Information

Keyboard: chavdai40/rev1
Revision (if applicable):
Operating system:
qmk doctor output:

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.0.0
Ψ QMK home: /Users/bigtreehouse/model_routine/keyboard/vial-qmk
Ψ Detected macOS 11.4.
⚠ QMK home does not appear to be a Git repository! (no .git folder)
Ψ CLI installed in virtualenv.
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 8.3.1
Ψ Found avr-gcc version 8.4.0
Ψ Found avrdude version 6.3
Ψ Found dfu-util version 0.11
Ψ Found dfu-programmer version 0.7.2
Ψ Submodules are up to date.
Ψ QMK is ready to go, but minor problems were found

Any keyboard related software installed?

• AutoHotKey (Windows)
• Karabiner (macOS)
• Other:

Additional Context

vial-kb/vial-qmk#158

raw_hid_receive can not work with via and vial

Write raw code in keymap.c

#ifdef RAW_ENABLE
void raw_hid_receive(uint8_t *data, uint8_t length) {
    if (data[0] == 1) {
        // default_layer_set(data[1]);
        layer_move(data[1]);
    }
    raw_hid_send(data, length);
}
#endif

When i run qmk compile -kb crkbd -km vial, and disable via and vial, It works well.

#VIA_ENABLE          = yes
#VIAL_ENABLE         = yes

But When i enable via and vial. It works error.

VIA_ENABLE          = yes
VIAL_ENABLE         = yes

error information:

Size before:
   text    data     bss     dec     hex filename
      0   25414       0   25414    6346 crkbd_rev1_vial.hex

Compiling: quantum/keymap_introspection.c                                                           [OK]
Compiling: quantum/via.c                                                                            [OK]
Linking: .build/crkbd_rev1_vial.elf                                                                 [ERRORS]
 |
 | d:/app/keyboard/qmk_msys/qmk_msys/mingw64/bin/../lib/gcc/avr/8.5.0/../../../../avr/bin/ld.exe: .build/obj_crkbd_rev1_vial/quantum/via.o (symbol from plugin): in function `via_eeprom_is_valid':
 | (.text+0x0): multiple definition of `raw_hid_receive'; .build/obj_crkbd_rev1_vial/quantum/keymap_introspection.o (symbol from plugin):(.text+0x0): first defined here
 | collect2.exe: error: ld returned 1 exit status
 |
make[1]: *** [builddefs/common_rules.mk:271：.build/crkbd_rev1_vial.elf] 错误 1
Make finished with errors
make: *** [Makefile:392：crkbd/rev1:vial] 错误 1

Is raw and via incompatible?

QMK settings not working

using keymap : https://github.com/linkpy/vial-qmk/tree/vial/keyboards/splitkb/aurora/sofle_v2/keymaps/vial

with qmk settings enabled, changing tapping term doesnt do anything (even setting it to a very high value like 1000ms doesnt seem to have any impact on the actual tap-hold behaviours).

i only tested this with LT_n keys.

to reproduice :

• enable qmk settings
• flash
• try to change the tapping term with the vial app
• notice nothing changes regarding key rolls and LT_n keys

[Bug] No OLED on Sofle keyboard

After flashing the keyboard with the firmware vial, the displays stay off when switching on.

• Keyboard: Sofle
• Operating system: Linux
• AVR GCC version: 10.2.0
• ARM GCC version: 10.2.0

编码器不能使用 Encoder cannot be used

多个不明确 映射到矩阵位置的，相同的配置 qmk下编译出来编码器可以用，也能via修改，vial-qmk直接编码器无反应不行，已经添加了VIAL_ENCODERS_ENABLE = yes

Multiple encoders that are not explicitly mapped to the matrix position can be used or modified via the encoder compiled under the same configuration qmk. The via qmk direct encoder has no response, and via has been added_ ENCODERS_ ENABLE = yes

[Bug]Libra Mini Can't Output Mouse Button Presses on Vial

The joystick moves the cursor with true analog input with the Vial firmware flashed, but the mouse button presses do not register even after mapped to the Libra Mini in Vial.

[Feature Request] Add workaround to work with gcc 12

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

On arch (and maybe some other rolling release distros) the current version of gcc is 12.1, and there's a bug ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523 ) which results in a bunch of error: array subscript 0 is outside array bounds of ... here and there. The problem is solved in the main qmk_firmware repo with 3 new lines of code in platforms/avr/platform.mk.

Basically, it'd be geat if you reflect the changes made with the following pull request:

• qmk/qmk_firmware#17136

And for now those who have the same problem can just go to the files section and copy-paste those 3 lines in the corresponding file.

KeyError: 'Matrix' bug is persistent.

I am facing this weird issue in vial where the matrix is not loading.
I was experimenting on a custom layout and got this error, First I thought I made some formatting error.
But after I rolled back to the previous working layout this error kept on popping. I replaced all the project files from vial and still getting this error. Tried reinstalling Vial but still no luck.
Any leads?

Error image

If TO(XX) exceeds 16 floors, an error will occur. For example, if 32 floors are enabled by config, if TO(0) is selected in vial, the actual output is TO(16), TO(1) is TO(17)...There is no within 16 floors this mistake

If TO(XX) exceeds 16 floors, an error will occur. For example, if 32 floors are enabled by config, if TO(0) is selected in vial, the actual output is TO(16), TO(1) is TO(17)...There is no within 16 floors this mistake

[Feature Request] Allow vial config to be done at a keyboard level.

Proposal

Currently to support vial with a keyboard the following needs to be done

• Add VIAL_KEYBOARD_UID to the config.h in the keymap folder
• Add vial.json to the keymap folder

What would be nice to have is to be able to add a keyboard variant that contains both the vial.json and config.h.

For example currently when you've got 2 keymaps supporting VIAL it look like this.
This would require the vial.json and config.h to be created 2 times

Folder structure now

keyboards/
├─ pieterv24/
│  ├─ testboard/
│  │  ├─ keymaps/
│  │  │  ├─ default/
│  │  │  │  ├─ keymap.c
│  │  │  ├─ pieterv24/
│  │  │  │  ├─ config.h
│  │  │  │  ├─ keymap.c
│  │  │  │  ├─ rules.mk
│  │  │  │  ├─ vial.json
│  │  │  ├─ vial/
│  │  │  │  ├─ keymap.c
│  │  │  │  ├─ rules.mk
│  │  │  │  ├─ vial.json
│  │  │  │  ├─ config.h
│  │  ├─ config.h
│  │  ├─ info.json
│  │  ├─ readme.md
│  │  ├─ rules.mk
│  │  ├─ testboard.c
│  │  ├─ testboard.h

My proposal would be to allow the following

Folder structure proposal

keyboards/
├─ pieterv24/
│  ├─ testboard/
│  │  ├─ keymaps/
│  │  │  ├─ default/
│  │  │  │  ├─ keymap.c
│  │  │  ├─ pieterv24/
│  │  │  │  ├─ keymap.c
│  │  │  │  ├─ rules.mk
│  │  ├─ vial/
│  │  │  ├─ vial.json
│  │  │  ├─ config.h
│  │  ├─ readme.md
│  │  ├─ rules.mk
│  │  ├─ testboard.c
│  │  ├─ testboard.h

In this configuration the idea would be that you could compile each keymap as a vial compatible keymap.
For example like this:
make pieterv24/testboard/vial:default
make pieterv24/testboard/vial:pieterv24

or without vial like:
make pieterv24/testboard:default
make pieterv24/testboard:pieterv24

Feature Request Type

• Core functionality
• Add-on hardware support (eg. audio, RGB, OLED screen, etc.)
• Alteration (enhancement/optimization) of existing feature(s)
• New behavior

[Feature Request] In-memory buffer for tap dance storage

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

In the current source, vial tap dance is handled by reading ROM directly to fetch its data. Would it be faster, easier to customize (code wise) and less taxing on the eeprom if:

• Tap dance is stored in a buffer in RAM, only commited to eeprom if press "save to rom"
• Tap dance buffer is loaded from eeprom after initializtion, like using keyboard_post_init_user
• User can setup their own TD slot in code after its loaded

Underglow Brightness and the Value of Underglow Color.

Setting the Value (as in HSV) of Underglow Color currently sets the Underglow Brightness for the entire keyboard (and vice versa).

This behavior prevents the user from setting different brightness/Value for individual LEDs using Lighting Layers, instead forcing the same value for the entire keyboard.

Suggestion: Underglow Brightness should work as an additional multiplier applied to LED brightness/Value instead of setting it directly. This way it would control the overall brightness while preserving the relative difference between LEDs.

[Bug] No oled on corne keyboard

After a recent update the oled stopped working on corne keyboard.

[Question] where do I enable set_unicode_input_mode?

I'm using the vial appimage, with an ergohaven k02 keyboard, and am unable to get unicode keycodes.

For reference, on an older keyboard (atreus62), I compile & apply qmk directly. In that keymap.c, I have the following:

void matrix_init_user(){
  set_unicode_input_mode(UC_LNX);
};

This enables me to use keycodes which emit unicode, eg: UC(0x03bb) gives "λ".

How do I configure this with vial?

Thanks in advance :)

Hello, I'm the designer of Libra Mini. I want to provide the original firmware file for you to refer to the rocker code

[Bug] Moved keyboard folders not reflected in vial

Describe the Bug

Some keyboards have been moved to different folders in upstream QMK and this change hasn't been reflect in vial-qmk yet.

Affected Keyboards

• adalyn -> tominabox1/adalyn
• ut472 -> keyhive/ut472 (PR)

Add midi support to vial's json, what should I write? Is there an example in keyboards?

Add midi support to vial's json, what should I write? Is there an example in keyboards? Where is it added?

get_current_wpm() always 0

I set wpm_enable = yes in my rule.mk，but get_current_wpm() is always 0, in old version is good working, is something change for vial-qmk broken it up?

tap-hold behavior

Is following behavior of tap-hold is correct?

E.g.) normaly alt, shift on tap_hold.

      |<--tapping term-->|
alt __|‾|___|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾ 
'a' ______________|‾|________|‾|___
                  'a'        'A'

If it's not the intention, I think it's better and natural behavior to fix this part as follows:

        if (state->pressed) return DOUBLE_HOLD;
        else if (state->interrupted) return DOUBLE_SINGLE_TAP;
        else return DOUBLE_TAP;

[BUG] Locked keyboard still allows for reading Matrix, editing keys, by VIA

A locked keyboard does not offer many of the immediately assumable security benefits of what seems to be advertised. When you come into VIAL and hear that you can lock your keyboard from modifications, that sounds great and dandy. My primary concern is silent matrix readout by an application that can talk to the keyboard over RAWHID. In reality this could extend to anything including Slack talking to your keyboard, and reading out its matrix. From reading out a keyboards matrix, you can start to assume some key placement, and start extracting messages, passwords, etc.

Describe the Bug

When VIAL keyboards are "locked" the matrix is still able to be read out, macros are able to be deleted, key maps are able to be changed.
This exposes you to silent keylogging from applications, and breaking keyboard functionality by a program that decides to overwrite all your layers.
Perhaps this has not been done in practice but nothing is stopping a program from doing something like this, and having the lock function actually lock the keyboard configuration would make a lot of sense.

Additional Context

What locking a keyboard should do, or at least allow us to toggle as an option, is restrict the matrix being read out to the pc to output only the keys defined in VIAL_UNLOCK_COMBO_ROWS and VIAL_UNLOCK_COMBO_COLS. While the keyboard is locked VIAL should also prevent writing to the keymap, or deleting macros.

You may say "but vial cannot read the matrix when the keyboard is locked"
Sure. But via can. https://usevia.app/#/